Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # user >> How to add optional new record fields and/or new methods in avro-ipc?

Copy link to this message
Re: How to add optional new record fields and/or new methods in avro-ipc?

On 10/18/11 10:38 AM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:

>On 10/18/2011 10:09 AM, Scott Carey wrote:
>> On 10/18/11 9:47 AM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:
>>> To amend this, you can use Avro's @Nullable annotation:
>> The problem is that this does not provide the ability to evolve schemas
>> you add a field
>> since you would need @Default or something similar, as well:
>> @Nullable
>> @Default(null)
>I don't think this is required.  The default value for a union is the
>default value for its first branch.  A "null" schema needs no default.
>So the schema ["null", "string"] needs to specify no default value while
>the schema ["string", "null"] does.  Thus the best practice for nullable
>values is to place the null first in the union.  This is what is done by
>the @Nullable annotation.

I have been successfully using default values for union fields with a
default of "null" and the first branch being a record with the Specific
I'm not sure that I understand "The default value for a union is the
default value for its first branch."
Defaults don't apply to any types in a union, only to fields on a record.
So the Schema ["Foo", "Bar"] can have no default, nor can any of its
A field with that schema as its type can have a default that is either a
"Foo" or a "Bar".

I think we may need to clarify all of this in the spec, the section on
records does not have an example using defaults, or mention what is a
permissible default for a union field.
>Perhaps we should clarify this in the Specification?  We might state
>that a "null" schema implicitly has a default value of null since that's
>the only value its ever permitted to have anyway.
>> Does reflect have any concept of default values?
>No.  We could add an @Default annotation, I suppose.  But I don't think
>this is needed for nullable stuff.