You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@avro.apache.org by Harsh J <qw...@gmail.com> on 2010/11/24 15:53:22 UTC
Parsing Anonymous Schema
Hello,
Is it possible to parse an "anonymous" record schema (back into a
proper Schema object)?
If I've created an anonymous record schema, I'm getting an error (No
"name" found, via Schema.parse() of Java API) when I de-serialize its
JSON to form a Schema object again.
Is this the intended behavior or is it a bug?
--
Harsh J
www.harshj.com
Re: Parsing Anonymous Schema
Posted by Doug Cutting <cu...@apache.org>.
On 11/24/2010 06:53 AM, Harsh J wrote:
> Is it possible to parse an "anonymous" record schema (back into a
> proper Schema object)?
>
> If I've created an anonymous record schema, I'm getting an error (No
> "name" found, via Schema.parse() of Java API) when I de-serialize its
> JSON to form a Schema object again.
>
> Is this the intended behavior or is it a bug?
Anonymous records are not permitted, according to the specification:
http://avro.apache.org/docs/current/spec.html#schema_record
This was done to simplify the specification and implementation of union
dispatch and schema resolution.
The Java implementation will let one programatically create and operate
on anonymous record schemas. This is done to share implementation with
protocol messages. But when such records are printed the generated JSON
is not parseable as a record schema.
Perhaps messages shouldn't be anonymous. Perhaps they should be a
record named with the protocol's namespace and the message name. But
that would prevent users from defining a record "foo" and also having a
message named "foo" and would not be back-compatible.
In summary, some possible ways we might address this:
- remove the ability to create anonymous records from the public API
- add javadoc warning that anonymous records cannot be parsed
- throw an exception when trying to print an anonymous record
- change messages to not be anonymous (incompatible)
- permit anonymous records in the specification (incompatible, complex)
Doug