[
https://issues.apache.org/jira/browse/AVRO-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15677224#comment-15677224
]
Frederic Boucher commented on AVRO-1903:
----------------------------------------
Hi Konstantin,
It allows us to have a different naming convention for our schema and our java
code and to workaround the few cases where people create schema which are named
with a java keyword.
This is built on the same model the Java stringType has been built: The actual
schema (.avsc file) does not contain these annotations. These annotations are
added to the SpecificRecord's internal schema during java code generation, are
only used internally by SpecificRecord reader, and are not required to be
shared with other systems/languages.
# * Relies on both class's generated by specific maven plugin, some people use
some alternative generation in other build tools such as sbt, as well as the
runtime Avro version.
I believe this change has no impact on other build tools.
# * What occurs where I have a shared generated Java bundle, yet some users are
on a previous Avro 1.8.x runtime version (mainly due to other third class
libraries, depending on them, Storm, Spark, general Hadoop eco-sphere)
If you have to share java classes generated with bindings, you wont be able to
use old Avro runtime to use them.
# * Files written in Java on Avro 1.8.x (We have 1.5 PB of these on our Hadoop
cluster) or before will not contain in their datum files the schema that has
this "magic" mapping/binding as such will cause a ClassNotFound if using
1.8.NEW with mapping/bindings
# * What occurs with compatibility with c clients, where they will write Avro
files without this special Java field.
As I explained above, the schema shared with other systems/languages does not
need to know about it.
# * Does this work with other languages such as Scala, Clojure that generally
build/reuse Java implementations?
I believe this won't be a problem as long they use a avro runtime compatible.
# * There is no testing.
Concerning the testing, we are happy to work on it if the community cans
consider integrating this feature in Avro once all problems have been fixed.
Happy to discuss further about it on a different discussion thread.
> 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)