Skip to content
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

[Avro] Add support for @AvroDefault and @Nullable annotations #49

Closed

Conversation

baharclerode
Copy link
Contributor

This adds support for embedding the default values (Provided by @AvroDefault or @JsonProperty) into the generated avro schemas. This also adds support for @Nullable in case there are multiple annotation introspectors in play and the annotations need to be recognized despite normally being the default.

I seem to have found a weird bug where if a property has a default value or a description, but is neither explicitly marked as required nor not required, POJOPropertyBuilder.getMetadata():503 will throw an NPE when it tries to coerce the required marker into a boolean primitive. I wasn't sure if this was intentional or something I don't fully understand. I worked around it by providing explicit required markers if @AvroDefault is present, but there's probably a better way to handle this that I'm not aware of. Normally this isn't a problem because @JsonProperty doesn't allow you to specify a default value or description without also setting the required marker to true or false.

Additional PRs for @AvroSchema, @AvroMeta, and @Union will probably be filed tomorrow sometime. The PR for adding polymorphic deserialization backported to the 2.8 branch will follow those.

@cowtowncoder
Copy link
Member

@baharclerode On NPE, it is fairly safe to say it is not intentional. I can't think of a reason to do so.
I can try to fix that.

Patch makes sense on its own, although I think reordering wrt default value is something that would actually be useful in at least one other place, where converting "resolving" deserializer (that is, one where separate reader/writer schemas are used).

One note on parsing default value: this will be bit of a pain to merge into master since I plan on using Avro 1.8 which changes handling to use plain Object, instead of Jackson 1.x tree model (to better encapsulate internal details).

@baharclerode
Copy link
Contributor Author

I think my final usecase requires avro 1.8.1 compatibility anyways (and jackson-dataformat-avro 2.8 is not compatible with 1.8.1), so I can just rebase this onto master and reopen a new pull request if you'd like.

@cowtowncoder
Copy link
Member

I think it'b great if you could add other pieces for Jackson 2.8, and I'll merge those, and then default handling for master (2.9)?

@cowtowncoder
Copy link
Member

Just realized that this will implement/fix #13.

// Appears to be a bug in POJOPropertyBuilder.getMetadata()
// Can't specify a default unless property is known to be required or not, or we get an NPE
// If we have a default but no annotations indicating required or not, assume required.
if (_hasAnnotation(m, AvroDefault.class) && !_hasAnnotation(m, JsonProperty.class)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think check for @JsonProperty should be needed here.
Is that only used to avoid NPE or for some other need?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only to work around the NPE. I just saw your message about fixing it, so I'll test everything with that and see if I can remove this workaround!

@cowtowncoder
Copy link
Member

@baharclerode I just fixed what was causing NPE you saw, I think. Fix in 2.8 branch, master.

@cowtowncoder
Copy link
Member

Btw, not related to this patch but I did some butchering for tests in master... apologies. Was having some issues with Lombok (I think), and didn't quite grok why exceptions caught differed (probably since one path wraps exceptions, other not). But on plus side, master builds again.

@baharclerode
Copy link
Contributor Author

Building is good! The test changes looked alright at a quick glance. I'm closing out this PR so that I can reopen it against master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants