avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: [RELEASE] Avro 1.3.3
Date Mon, 14 Jun 2010 22:08:04 GMT
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

Mime
View raw message