[
https://issues.apache.org/jira/browse/AVRO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300404#comment-17300404
]
Emilio Jose Mena Cebrian commented on AVRO-2838:
------------------------------------------------
I suggest a patch.
>From my point ov view, modifying original Schema to include
>technology-specific instructions to the decoder is a bad design because the
>point of using schemas is to describe data, not how the data is decoded,
I understand that passing these parameters using the schema is a very easy
solution because of the way parameters are passed from method to method in
*DatumReader.
I also understand that the goal of the schema included with Java classes is to
decode messages, not to be "the source of truth", but some third party software
is using it as a source of the Avro schema. (yes, I'm aware that you can't be
aware of all other projects)
My suggestion is to include source schema and an accessor to It in
GenericContainer.
{{Schema getSourceShema()}}
If no modifications are made to the schema, both {{getSourceSchema()}} and
{{getSchema()}} will return the same instance.
Maybe you'll need a static method too in generated classes (like
{{getClassSchema()}} method)
The diference is that you +give the oportunity+ to others to know the source
schema.
For example, you give Confluent the oportunity of use the original schema
instead of the modified one to use their schema-registry
You can't change other projects, but you can help them by publishing the
original schema
(and keep using the modified one to decode contents )
> Schema in generated Java class is different than the original one
> -----------------------------------------------------------------
>
> Key: AVRO-2838
> URL: https://issues.apache.org/jira/browse/AVRO-2838
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Reporter: Lukas Krecan
> Priority: Major
> Attachments: AVRO.patch
>
>
> If you generate Java classes from schema, {{SCHEMA$}} variable differs from
> the original schema. It causes issues like
> [this|https://github.com/confluentinc/schema-registry/issues/868] and
> [this|https://github.com/confluentinc/schema-registry/issues/1352] when using
> Schema registry.
> The issue happens when the schema in the registry is configured externally
> and then you try to use generated Java class. The schema in the registry does
> not match the schema in the class and thus the write is refused.
> Technically it's easy to fix (see the attached patch) but I guess there will
> be some backward compatibility concerns.
> If it is not acceptable, would it be at least possible to add the
> {{originalSchema}} context variable so we could solve it using custom
> template.
> The patch is not final, its purpose is just to convey the idea.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
