You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by Matt Massie <ma...@cloudera.com> on 2009/11/07 02:26:50 UTC

Interop map question

I'm working on C interoperability tests and I think I've find an
inconsistency.

In interop.avsc we have...

{"type": "map", "keys": "long", "values":
        {"type": "record", "name": "Foo",
         "fields": [{"name": "label", "type": "string"}]}}},

...for the map field.  Looking at the Java and python code, the key is
always read/written as utf8.  My C code was trying to read the keys as longs
(since that is what the schema has).  When I changed "long" to "string", it
worked.

Is the correct behaviour to honor the "keys" type if it exists?

Thanks for the help!
-Matt

Re: Interop map question

Posted by Matt Massie <ma...@cloudera.com>.
Added to...

https://issues.apache.org/jira/browse/AVRO-186

Thanks for the quick response guys.

-Matt

On Sun, Nov 8, 2009 at 9:40 PM, Sharad Agarwal <sh...@yahoo-inc.com>wrote:

> Scott Banachowski wrote:
>
>> Hi Matt,
>>
>> I think the "key" attribute was removed from the spec, because keys are
>> always supposed to be string.  It was probably never removed from the
>> schema
>> you are using, but the attribute is probably ignored by the other
>> implementations.
>>
>>
>
> That is correct. Matt you may want to remove the redundant "key" attribute
> from interop.avsc as part of your patch.
>
> Thanks
> Sharad
>

Re: Interop map question

Posted by Sharad Agarwal <sh...@yahoo-inc.com>.
Scott Banachowski wrote:
> Hi Matt,
>
> I think the "key" attribute was removed from the spec, because keys are
> always supposed to be string.  It was probably never removed from the schema
> you are using, but the attribute is probably ignored by the other
> implementations.
>   

That is correct. Matt you may want to remove the redundant "key" 
attribute from interop.avsc as part of your patch.

Thanks
Sharad

Re: Interop map question

Posted by Scott Banachowski <sb...@yahoo-inc.com>.
Hi Matt,

I think the "key" attribute was removed from the spec, because keys are
always supposed to be string.  It was probably never removed from the schema
you are using, but the attribute is probably ignored by the other
implementations.

Scott




On 11/6/09 5:26 PM, "Matt Massie" said:

> I'm working on C interoperability tests and I think I've find an
> inconsistency.
> 
> In interop.avsc we have...
> 
> {"type": "map", "keys": "long", "values":
>         {"type": "record", "name": "Foo",
>          "fields": [{"name": "label", "type": "string"}]}}},
> 
> ...for the map field.  Looking at the Java and python code, the key is
> always read/written as utf8.  My C code was trying to read the keys as longs
> (since that is what the schema has).  When I changed "long" to "string", it
> worked.
> 
> Is the correct behaviour to honor the "keys" type if it exists?
> 
> Thanks for the help!
> -Matt