Mailing-List: contact user-help@avro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@avro.apache.org
Received-SPF: pass (nike.apache.org: domain of johntbates@gmail.com designates
 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALEq1Z-efyVx0AvxOn0EL80eB2SoH6Lpy7Gzx5whmp8++Sb2kA@mail.gmail.com>
References: 
 <CAM_WawyepXDCZQdYnnmsQDkbq352w-wcm9083JzX67ns39NmDQ@mail.gmail.com>
	<CALEq1Z-efyVx0AvxOn0EL80eB2SoH6Lpy7Gzx5whmp8++Sb2kA@mail.gmail.com>
Date: Wed, 6 Jun 2012 16:16:33 -0700
Message-ID: 
 <CAM_WawxhWN9XeU_3Jimcb3jJ-Oe7HTB6+UJc_f7GApf2Xh-VPg@mail.gmail.com>
Subject: Re: robustness of Schema.Field.pos() across schema versions
From: John Bates <johntbates@gmail.com>
To: user@avro.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks very much, Doug.  It seems as though we might abandon that
approach and only support Avro data, but I appreciate your thorough
response!

Thanks again,
bates

On Wed, Jun 6, 2012 at 3:46 PM, Doug Cutting <cutting@apache.org> wrote:
> John,
>
> I think this will work fine. =A0The schema in SCHEMA$ is in sync with
> the generated code.
>
> You should be able to avoid this copying by instead generating code
> with a different base class that contains your methods. =A0In
> particular, it should be easy to modify record.vm to instead use a
> subclass of SpecificRecordBase. =A0Templates are found on the classpath.
>
> We might also add a feature where one can specify an alternate base
> class through an API. =A0This might then be used by the Maven and Ant
> tasks. =A0If that approach sounds useful, please file an issue in Jira.
>
> Doug
>
> On Wed, Jun 6, 2012 at 1:08 PM, John Bates <johntbates@gmail.com> wrote:
>> Hi, all.
>>
>> I'm trying to subclass an Avro IDL-generated class so that it may
>> implement an interface used by our project to deserialize data (and
>> not necessarily Avro data) from an InputStream. =A0Ideally, I'd like to
>> do something like this:
>>
>> public class MySubclass extends MyAvroGeneratedClass implements
>> MySerializationInterface {
>> =A0@Override
>> =A0public void readObject(InputStream in) throws IOException,
>> =A0 =A0 =A0ClassNotFoundException {
>>
>> =A0 =A0// AvroUtil.readObject exists and returns a SpecificRecord given
>> an InputStream and Schema
>> =A0 =A0MySubclass other =3D ((MyAvroGeneratedClass) AvroUtil.readObject(=
in,
>> MyAvroGeneratedClass.SCHEMA$));
>>
>> =A0 =A0// Is this correct? =A0Is it robust?
>> =A0 =A0List<Schema.Field> fields =3D other.getSchema().getFields();
>> =A0 =A0for(Schema.Field field : fields) {
>> =A0 =A0 =A0field.name();
>> =A0 =A0 =A0int position =3D field.pos();
>> =A0 =A0 =A0this.put(position, other.get(position));
>> =A0 =A0}
>> =A0}
>> }
>>
>> I'm trying to avoid having to use the setters and getters supplied by
>> the generated class, as that will require this subclass remains in
>> sync with the IDL-generated class, which will probably be a point of
>> failure.
>>
>> Is this approach robust to changes in the schema? =A0That is, if the
>> schema changes at some point in the future, will it be possible to
>> deserialize data that has been serialized with an older version of the
>> schema? =A0Is there a better (read: more correct, more robust, more
>> consistent with Avro's design) way to do this?
>>
>> I sincerely appreciate your help - I've been blocked for a few days on t=
his.
>>
>> Thanks in advance,
>> John Bates