Yes, we certainly need better documentation here.
The FAQ in the wiki is a fine place to start.
We should also probably improve the official documentation, e.g., the
spec and javadocs. For example, the table mapping Avro types to Java
types in the generic docs should perhaps be linked to from the specific
and reflect documentation. And more examples would help, both in the
docs and perhaps in the src/test code tree, or in a new src/examples
tree. Maybe we need a Java tutorial document, walking through use of
each API?
Doug
George Porter wrote:
Thanks for this clarification. Looking closer at the spec that does make sense.
Since both tazan007 and I were thrown by it, maybe we could make that
more explicit or add it to a FAQ? I'd be happy to update the wiki as
appropriate. Thoughts?
-George
On Thu, Aug 6, 2009 at 2:38 PM, Doug Cutting<[email protected]> wrote:
tazan007 wrote:
Caused by: org.apache.avro.SchemaParseException: Type not yet supported:
string
[ ...]
Is this expeceted behavior? Do the types have to be complex if they are
named types?
Yes. The only named types are record, enum, and fixed, and only these are
permitted in the "types" section of a protocol.
http://hadoop.apache.org//avro/docs/current/spec.html#Protocol+Declaration
Like Java, Avro protocols have no typedef. You could instead define a
record with a single field. This would not alter what's serialized, since
records add no serialization overhead, but would make for stronger typing.
Doug
