[
https://issues.apache.org/jira/browse/AVRO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171487#comment-17171487
]
Ryan Skraba commented on AVRO-2838:
-----------------------------------
Yeah, I agree -- generated classes should not be modifying the schema that the
user carefully provided, even to annotate it with information about how the
specific compiler was configured at the time (notably how the string class was
set). That's nice for "reproducible" class generation with just the schema.
I like the configuration property idea: I suggest
{{annotateSchemaWithCompilerOptions}} set to {{true}} by default for 1.10.1.
How does this sound? Is there any need to have both schemas?
> 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)
