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
