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

Switch to Plain View
Avro, mail # user - Could specific records implement the generic API as well?


+
Christophe Taton 2013-04-15, 18:23
+
Doug Cutting 2013-04-15, 20:08
+
Scott Carey 2013-04-15, 19:46
+
Christophe Taton 2013-04-15, 21:21
+
Doug Cutting 2013-04-15, 22:43
+
Christophe Taton 2013-04-18, 20:18
+
Doug Cutting 2013-04-22, 20:19
+
Scott Carey 2013-04-16, 04:19
+
Christophe Taton 2013-04-16, 04:39
+
Christophe Taton 2013-04-17, 05:30
Copy link to this message
-
Re: Could specific records implement the generic API as well?
Pankaj Shroff 2013-04-17, 14:16
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]