-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
generate POJO methods getPrimaryIdentifier and getAdditionalIdentifiers #103
Conversation
note that the build works locally but fails here because the RPDK does not have the new schema with primaryIdentifier and additionalIdentifier |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to update identifier handling in CloudFormation before we merge the new schema to RPDK, and then this can land. 👍
Need to add some tests to the generated code, and include them in the /templates source that is generated as part of the package. The test can make sure that the correct identifiers from the schema are parsed for example. |
python/rpdk/java/codegen.py
Outdated
contents = template.render( | ||
type_name=project.type_name, | ||
package_name=self.package_name, | ||
properties=pojos["ResourceModel"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: these args are there because I was going to try to generate values in order to get the test coverage up. will remove these if we're settled on this being not necessary
You should add some more tests around the identifier generation; use compound keys, multiple primaryIdentifiers, bad paths, etc. Then, you can fix the build by excluding the Like |
public void test_ResourceModel_SimpleSuccess() { | ||
final ResourceModel model = ResourceModel.builder().build(); | ||
|
||
assertThat(model.getPrimaryIdentifier(), is(not(nullValue()))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add some more complex schemas for testing these additions? If we test the generation here, we can exclude the generated ResourceModel.java
POJO from the package coverage expectations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do. The problem is that if we can't test the logic anyway (without generating values) there isn't really any good way to verify that this will generate properly for any schema
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have tests which verify the pojo_resolver with different schemas so thats most of it there. The only untested part (automated at least) is the identifier methods, and this is non trivial to test since it would require generating values, or creating some other strategy. I have raised #119 to address this.
I've done manual testing with:
- one identifier
- compound identifier
- multiple additional identifiers
- no additional identifiers
- up to four levels deep of nesting in an identifierpath
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does the use-case look like for this? I get how getPrimaryIdentifier
is useful, but am struggling to see how getAdditionalIdentifiers
would be used the current form. Since additionalIdentifiers
is a list with list/array semantics, intuitively null
values should be preserved to preserve indices. Unless you only cared about the first valid one - but then this code could short-circuit earlier.
So without examples how these might be used, I'm really not sure what makes sense here.
|
||
public class ResourceModelTest { | ||
@Test | ||
public void test_ResourceModel_SimpleSuccess() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unnecessary test_
prefix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
k
I envision this being used by the read handler, since you can pass any set of identifiers it would allow for a quick validation check and easy access to a set of identifiers. |
Issue #, if available: #95
Description of changes:
An important assumption in the POJO file is that IdentifierPaths will always begin with
/properties/
, which I believe this will always be the case.Example:
Given schema
we generate
On the POJOs for the subObjects we don't see these methods
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.