You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by Jeff Hammerbacher <ha...@cloudera.com> on 2010/06/14 04:04:05 UTC

[RELEASE] Avro 1.3.3

Hey,

I'd like to announce the release of Apache Avro 1.3.3. The release notes are
available at http://s.apache.org/avro-1.3.3, and you can download the new
bits from http://avro.apache.org/releases.html. This release includes
important bug fixes for the Python and Ruby implementations and incremental
improvements for the Java, C++, and C implementations.

Thanks for all of the bug reports, patches, and code reviews. More Avro
goodness to come!

Thanks,
Jeff
<http://cassandra.apache.org/download>

Re: [RELEASE] Avro 1.3.3

Posted by Doug Cutting <cu...@apache.org>.
On 06/14/2010 02:22 PM, R. Tyler Ballance wrote:
> In my case, I already have "string" as part of my errors union (passing back
> errors as JSON in some cases) so now my schemas rase SchemaParseExceptions
> (http://avro.pastebin.com/pfSempR7).

The intent in the spec was that user errors would all be records defined 
in the protocol with the "error" keyword, in other words, that a 
message's error union was not an arbitrary union, but restricted to that 
type of record.  This permits code generation of different exception 
classes in languages like Java, C++, etc.

But the spec unfortunately doesn't make that entirely clear, and most 
implementations probably don't check that error unions only contain 
errors defined this way.

This is something that AVRO-561 should help to prevent.  I just voted 
for that issue.

https://issues.apache.org/jira/browse/AVRO-561

> I'm curious if it's intentional to raise an exception on duplicate types in the
> union

Yes.  This permits implementations to use runtime typing when writing a 
union.  Otherwise union values would have to be wrapped in something 
that declared which branch was intended.

> if so, what's my best course of action here? Switch to 1.3.3 across the
> board all at once while changing my schemas (eek!)?

Ugh.  I wonder if you could somehow hack the runtime so that, when a 
union has two strings at the start it ignores one, silently combining 
those two branches.  Then you could update your protocols, and, once 
that's complete, remove the hack.  Could something like that work?

Doug

Re: [RELEASE] Avro 1.3.3

Posted by "R. Tyler Ballance" <ty...@monkeypox.org>.
On Sun, 13 Jun 2010, Jeff Hammerbacher wrote:

> Hey,
> 
> I'd like to announce the release of Apache Avro 1.3.3. The release notes are
> available at http://s.apache.org/avro-1.3.3, and you can download the new
> bits from http://avro.apache.org/releases.html. This release includes
> important bug fixes for the Python and Ruby implementations and incremental
> improvements for the Java, C++, and C implementations.

It looks like r951219 breaks Python RPC compatibilyt with previous releases
since the "string" type is now part of the `errors` union.

In my case, I already have "string" as part of my errors union (passing back
errors as JSON in some cases) so now my schemas rase SchemaParseExceptions
(http://avro.pastebin.com/pfSempR7).

I'm curious if it's intentional to raise an exception on duplicate types in the
union, if so, what's my best course of action here? Switch to 1.3.3 across the
board all at once while changing my schemas (eek!)?

Cheers,
-R. Tyler Ballance
--------------------------------------
  Jabber: rtyler@jabber.org
  GitHub: http://github.com/rtyler
Identica: http://identi.ca/dero
 Twitter: http://twitter.com/agentdero
    Blog: http://unethicalblogger.com