Hello,

  Is mapping of avro arrays to java arrays instead of lists, still being
planned?

Thanks
Sameer

From: Scott Carey <[email protected]>
To: "[email protected]" <[email protected]>
Date: Wed, 27 Apr 2011 12:09:02 -0700
Subject: Re: runtime error when casting Array<String> to String[]
Thread-Topic: runtime error when casting Array<String> to String[]
Thread-Index: AcwFDouwWK6P0HsIQBW0+lsPhRTwlQ==
Message-ID: <c9ddb584.31ee5%[email protected]>
In-Reply-To: <[email protected]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0



On 4/27/11 11:26 AM, "Markus Weimer" <[email protected]> wrote:

>HI,
>
>> I am working on tools for Avro that will make Alternate object mappings
>>easier.  I hope this will land in 1.6.0.  Custom specific compiled
>>variants will more easily leverage all the work unrelated to object type
>>mapping.
>
>Nice! Will that allow me to have an array of floats in the schema and
>receive it as a float[] in the compiled java class?
>

It will allow users to create custom mappings easier, one of which might
be that avro arrays that map to java array types instead of List.  A few
basic mapping types might find their way into Avro if they are contributed.

The Specific compiler has been templatized for a while now, and users can
create their own code templates that produces classes as they like, but
writing a custom SpecificDatum(Reader|Writer) requires knowing a lot about
things unrelated to the mapping of Avro types to Java types.

Creating a custom mapping isn't always trivial, but having it be a
separate concern from schema translation and resolution, and low level
encoding/decoding operations will allow for greater code re-use and
modular composition.

>Thanks,
>
>Markus

Reply via email to