avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Blue <rb...@netflix.com.INVALID>
Subject Re: Avro union compatibility mode enhancement proposal
Date Mon, 18 Apr 2016 20:11:42 GMT
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
unknown.

rb

On Mon, Apr 18, 2016 at 12:59 PM, Doug Cutting <cutting@gmail.com> wrote:

> 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 <rblue@netflix.com.invalid>
> wrote:
> > 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 <cutting@gmail.com>
> wrote:
> >
> >> On Sun, Apr 17, 2016 at 2:00 PM, Matthieu Monsch <monsch@alum.mit.edu>
> >> 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 new union syntax (e.g.,
> >> {"type":"union", "branches":[...], "default":...}) then existing
> >> implementations will not be able to read new data that uses this
> >> feature.
> >>
> >> Doug
> >>
> >
> >
> >
> > --
> > Ryan Blue
> > Software Engineer
> > Netflix
>



-- 
Ryan Blue
Software Engineer
Netflix

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message