avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: Effort towards Avro 2.0?
Date Tue, 03 Dec 2013 15:20:55 GMT
On Mon, Dec 2, 2013 at 1:56 PM, Philip Zeyliger <philip@cloudera.com> wrote:
> It sounds like you're proposing to break language API compatibility.  Are
> you also proposing to break wire compatibility for Avro HTTP RPC, Avro Netty
> RPC, and/or Avro datafiles?

We should be able to provide back-compatibility.  When current APIs
cannot be back-compatibly extended, new APIs can be added.  Old APIs
may be deprecated but should be retained for a while.  Data files
written by 1.x should be readable by 2.x.

Forward compatibility may not be possible when new schema features are
used.  Data files written in 2.x may not be readable by 1.x.  Perhaps
we could add a mode that forces 2.x to write a 1.x format file.

RPC interoperability requires that 2.x be able to both read and write
1.x format.  So long as a 1.x protocol is used, then 1.x and 2.x
clients and servers might be able to interoperate using 1.x wire
formats.  But when 2.x schema features are used this may not be

Perhaps we should proceed by making back-compatibility (ability to
read 1.x) a requirement, then adding interoperabilty features (ability
to write 1.x) as needed?

Should we require that all new schema features (named unions,
extensions, date primitive, etc,) have a lossless translation to a 1.x


View raw message