avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Re: schema defaults not reflected in generated objects (1.3.2)
Date Sat, 04 Sep 2010 02:09:02 GMT

Sorry to dredge up such an old thread, but...

On Mon, 2010-06-07 at 15:30 -0700, Doug Cutting wrote:
> On 06/07/2010 03:11 PM, Bill de hOra wrote:
> > This means writers can't leverage schema defaults, so writers should do
> > something like this?
> >
> > Message message = new Message();
> > // no defaults set
> > String quux = message
> > .getSchema()
> > .getField("foo")
> > .defaultValue()
> > .getTextValue();
> > message.foo=new Utf8(quux);
> >
> > [ignoring that the writer needs to know the schema type]. I suspect
> > people will just write in garbage (like empty strings).
> No, we don't expect folks to do that.  If a writer never sets a field 
> then they might be better off dropping that field from their schema.  If 
> the writer only rarely sets it, then a schema which is a union with null 
> might be better, making the field optional.  But if the field is usually 
> set but it's awkward for the programmer to know whether its set, then 
> automatically filling in a default might be a useful feature and the 
> default from the schema is probably a good value to use.

FWIW, the situation that keeps reoccurring in Cassandra is one where
there are sane defaults that work 90% of the time.  Using factories to
apply defaults will work, but then they would need to be kept in sync
across all of the clients (of which there are many).  Making the field
optional and applying the defaults on the server side will work, but
these defaults are technically part of the schema and it seems less than
optimal to separate them like this (and it hides the defaults from

> Like Philip, I too am +1 for enhancing the SpecificCompiler to set 
> default values from the schema in generated code.  The only downside I 
> see is perhaps a slight performance loss: if the default value is always 
> overwritten then the allocation and setting of it will still be executed 
> for each instance.

This covers Java when generated classes are used, but the other writers
would need to be changed as well.  I'm willing to work on patches for
this, is this still something you'd considering merging?  Should it be
made optional?

Eric Evans

View raw message