*@Lewis:*
Now that I have been thinking about it more, looks like my way would end up
causing an issue: I add the dirty field to each original schema obj after
queuing the original schemas. This would end up causing one problem: the
nested appearances would not refer to the modified schema with "dirty" but
with the original schema. Certainly something that we don't want.
*@Renato:*
> The link you provided is for Avro SpecificCompiler mate ;) was that
intended?
Yup. GoraCompiler extends this Avros' compiler and it was worth looking at
that code would have had the same problem !!!
*@Scott*
The schema seems correct to me. Below is an example from Avro website [0]:
For example, a linked-list of 64-bit values may be defined with:
{
"type": "record",
"name": "LongList",
"aliases": ["LinkedLongs"], // old name for this
"fields" : [
{"name": "value", "type": "long"}, // each element has a
long
{"name": "next", "type": ["LongList", "null"]} // optional next element
]
}
Here Longlist refers to itself... pretty similar to what Lewis' example [1]
does :
"type": "record",
"name": "Employee",
"fields" : [
...........
...........
{"name": "boss", "type":["null","Employee","string"]},
[0] : http://avro.apache.org/docs/current/spec.html#schema_record
[1] :
http://svn.apache.org/repos/asf/gora/branches/GORA_94/gora-core/src/examples/avro/employee.json
Thanks,
Tejas
On Sun, Aug 25, 2013 at 8:34 AM, Scott Stults <
[email protected]> wrote:
> Lewis,
>
> In your schema, should the type for boss be a union of null and an array
> of Employee?
>
> >
> > {"name": "boss", "type":["null","Employee","string"]},
>
>
> -Scott
