[
https://issues.apache.org/jira/browse/AVRO-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15692686#comment-15692686
]
konstantin commented on AVRO-1903:
----------------------------------
Thanks for replying.
Unfortunately i think you've missed the point we were trying to raise with
back/forward compatibility issues.
Avro has always ensured this.
An Avro datum file when written by a SpecicDatumWriter stores both the binary,
and the schema for that in the file.
If i have a datum file written with 1.8.0 this contains both the schema and the
data. At this point the schema in that datum file WILL NOT contain your magic
schema props.
Then if i go try read this with a process that is on 1.8.BINDINGS, when the
SpecificDatumReader reads the datum file, it will read the schema, from the
datum file, and try find this on the class path. Because the magic info isn't
there telling it to look for a different class, it will get a class not found
issue.
The same issue will apply where other systems will continue to write data to
hadoop without these props but consumed by the new application, generated with
bindings. Older processes on earlier versions producing, and like wise other
languages producing.
This is different to the UTF8 / Strings, as both of these WILL be on the
classpath, as such won't fail with a class not found, and will be able to get
the SpecificRecord schema, and perform up conversion where expecting String,
and like wise down conversion need not worry.
Obviously this would become very evident if there was a good suite of tests
around this, especially on backward forward compatibility, for a multi tenanted
environment which Hadoop is, and Avro is quite universal.
> Java package/class bindings for specific records
> ------------------------------------------------
>
> Key: AVRO-1903
> URL: https://issues.apache.org/jira/browse/AVRO-1903
> Project: Avro
> Issue Type: New Feature
> Components: java
> Affects Versions: 1.8.1
> Reporter: Frederic Boucher
> Attachments: AVRO-1903.patch
>
>
> Naming convention of the Avro schemas we create are not always in line with
> the Java coding convention. The maven-plugin to generate specific record
> classes should provide a way to bind namespace or schema names to a custom
> Java package or class name.
> We have implemented a solution where we can add bindings into the
> maven-plugin configuration:
> One to one binding:
> <binding>
> <from>com.namspace.order.state</from>
> <to>com.package.Order</to>
> </binding>
> It will create a class "Order" into package "com.package" for schema "state"
> and namespace "com.namspace.order"
> Reg-exp based binding:
> <binding>
> <from>com.namespace.order.([a-zA-Z]+)</from>
> <to>com.package.order.Order$1</to>
> </binding>
> Bindings are matched in order, which means the most specific bindings have to
> be put before the generic ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
