Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # user >> Could specific records implement the generic API as well?


Copy link to this message
-
Re: Could specific records implement the generic API as well?
This *could* get us closer to implementing a new "reader" extending
DatumReader that reads text/json and generates Avro records (even
SpecificRecord records). Vice versa - one could similarly write a new
"writer" extending the base class DatumWriter that takes an avro
SpecificRecord and spits out a text/json representation (without the Avro
adornments that are required).

Combined with the technique using GenericRecordBuilder described by Doug in
the email thread, such a new "reader"/ "writer" *could* allow building
SpecificRecords that have a Schema from text/json strings - thus removing
the requirement that you must use a JsonEncoder to create Json strings
before reading/parsing them using JsonDecoder.

I will do some experiments and post findings in a separate thread.
On Wed, Apr 17, 2013 at 1:30 AM, Christophe Taton <[EMAIL PROTECTED]>wrote:

> I created https://issues.apache.org/jira/browse/AVRO-1299 and posted a
> patch to let SpecificRecordBase implement GenericRecord.
>  As I think about it, it seems to me that SpecificRecordBuilderBase should
> also implement GenericRecord.
>
> C.
>
>
> On Mon, Apr 15, 2013 at 9:39 PM, Christophe Taton <[EMAIL PROTECTED]>wrote:
>
>> On Mon, Apr 15, 2013 at 9:19 PM, Scott Carey <[EMAIL PROTECTED]>wrote:
>>
>>> I would like to figure out how to make SpecificRecord and GenericRecord
>>> immutable in the longer term (or as an option with the code generation
>>> and/or builder).  The builder is the first step, but setters are the
>>> enemy.  Is there a way to do this that does not introduce new mutators
>>> for
>>> all SpecificRecords?
>>>
>>
>> That's fair. Getters only would work for what I need, assuming setters
>> will eventually come through builders.
>>
>> And Immutable records would be great!
>>
>> C.
>>
>> On 4/15/13 3:43 PM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:
>>>
>>> >On Mon, Apr 15, 2013 at 2:21 PM, Christophe Taton <[EMAIL PROTECTED]>
>>> >wrote:
>>> >> If you think it's a meaningful addition, I'm happy to make the change.
>>> >
>>> >The two methods I wrote above could be added to SpecificRecordBase and
>>> >it could then be declared to implement GenericRecord.
>>> >
>>> >I think GenericRecordBuilder could be used to build specific records
>>> >with a few additional changes:
>>> > - change the type of the 'record' field from GenericData.Record to
>>> >GenericRecord.
>>> > - replace the call to 'new GenericData.Record()' to
>>> >'(GenericRecord)data().newRecord(null, schema())'
>>> > - add a constructor that accepts a GenericData instance, instead of
>>> >calling GenericData.get().
>>> >
>>> >Then you could use new GenericRecordBuilder(SpecificData.get(),
>>> >schema) to create specific records.
>>> >
>>> >Doug
>>>
>>>
>>>
>>
>
--
Pankaj Shroff
[EMAIL PROTECTED]
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB