Re: Avro union compatibility mode enhancement proposal

2016-04-18 Thread Doug Cutting
I was responding to the "For unions, we will add an optional catch-all attribute" part. The syntax of union schemas is unfortunately hard to modify compatibly. Here's a way around that. Recall that every kind of schema, except union, supports arbitrary properties, and unions cannot be directly

[jira] [Created] (AVRO-1831) Take advantage of JSR 3.5 annotations in the generated java classes.

2016-04-18 Thread Zoltan Farkas (JIRA)
Zoltan Farkas created AVRO-1831: --- Summary: Take advantage of JSR 3.5 annotations in the generated java classes. Key: AVRO-1831 URL: https://issues.apache.org/jira/browse/AVRO-1831 Project: Avro

Re: Avro union compatibility mode enhancement proposal

2016-04-18 Thread Ryan Blue
Doug, I don't think I understand. Why would this change a union representation? This wouldn't change the schema format, other than to add an attribute to enum types that is ignored by older readers. New readers will use that attribute to determine which symbol to use when the written symbol is

Re: Avro union compatibility mode enhancement proposal

2016-04-18 Thread Doug Cutting
Perhaps then its sufficient to only write the new schema format when the new attribute is specified, so existing apps will continue to represent unions as JSON arrays? If so, this should probably be written into the spec. On Mon, Apr 18, 2016 at 12:52 PM, Ryan Blue

Re: Avro union compatibility mode enhancement proposal

2016-04-18 Thread Ryan Blue
Isn't the problem that these changes aren't compatible right now anyway? If I need to add an entry to an enum right now, older readers fail when trying to handle that data. This creates a way to avoid that failure in new versions. On Mon, Apr 18, 2016 at 12:48 PM, Doug Cutting

Re: Avro union compatibility mode enhancement proposal

2016-04-18 Thread Doug Cutting
On Sun, Apr 17, 2016 at 2:00 PM, Matthieu Monsch wrote: > + For unions, we will add an optional catch-all attribute to mark a branch as > resolution target when no names or aliases match (and come up with the > corresponding syntax). Can this be compatible? If you add a

[jira] [Commented] (AVRO-1708) Memory leak with WeakIdentityHashMap?

2016-04-18 Thread Ryan Blue (JIRA)
[ https://issues.apache.org/jira/browse/AVRO-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246016#comment-15246016 ] Ryan Blue commented on AVRO-1708: - We're replacing the use of weak and identity hashmaps with guava

[jira] [Commented] (AVRO-1827) Handling correctly optional fields when converting Protobuf to Avro

2016-04-18 Thread Jakub Kahovec (JIRA)
[ https://issues.apache.org/jira/browse/AVRO-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245722#comment-15245722 ] Jakub Kahovec commented on AVRO-1827: - Thank you [~rdblue] for your response. I've added a new patch

[jira] [Updated] (AVRO-1827) Handling correctly optional fields when converting Protobuf to Avro

2016-04-18 Thread Jakub Kahovec (JIRA)
[ https://issues.apache.org/jira/browse/AVRO-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakub Kahovec updated AVRO-1827: Attachment: AVRO-1827.patch Updated patch including tests > Handling correctly optional fields when