[
https://issues.apache.org/jira/browse/AVRO-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17561914#comment-17561914
]
Kalle Niemitalo commented on AVRO-3570:
---------------------------------------
In the C# library, I'd prefer deleting the Schema.Type.Logical constant and the
LogicalSchema class, and instead adding a Schema.LogicalType property like in
the Java library.
* Pro: Clean solution.
* Con: Would break the public API.
* Con: Would break compatibility with any existing schemas that use a nested
object as "type" with a logical type. This would be especially bad if data
encoded using such a schema has been persistently stored (e.g. in a Kafka
topic) with a schema identifier, and the application then tries to decode this
data and fetches the schema from a schema registry but cannot even parse the
schema.
Alternatively, it would be possible to support both JSON structures, by adding
a NamedSchema.LogicalParent property that references the LogicalSchema that was
parsed from the same JSON object as this NamedSchema, or is null if the
NamedSchema was instead parsed from a nested JSON object in the "type"
property. The Schema.ParseJson method would then check the
NamedSchema.LogicalParent property after SchemaNames.TryGetValue returns true.
- Pro: The name would always refer to the schema that was parsed from the JSON
object that has the "name" property. This behavior would be compatible with
schemas supported by the Java implementation, and also compatible with schemas
supported by older versions of the C# implementation. And I think it's what
users expect anyway.
- Pro: LogicalSchema would still extend UnnamedSchema rather than NamedSchema.
Keeping the class hierarchy unchanged would minimize the compatibility risk.
- Con: The API might become confusing for developers who build schemas
programmatically instead of calling Schema.Parse.
- Con: C# developers who are not aware of this issue might inadvertently
create new schemas that are not compatible with the Java implementation. This
could be mitigated by making avrogen warn about them.
[https://json.schemastore.org/avro-avsc.json] appears to disallow a nested
object as "type" already.
> Logical type with "fixed" type not interoperable
> ------------------------------------------------
>
> Key: AVRO-3570
> URL: https://issues.apache.org/jira/browse/AVRO-3570
> Project: Apache Avro
> Issue Type: Bug
> Components: csharp, doc, logical types, rust
> Affects Versions: 1.11.0
> Reporter: Kalle Niemitalo
> Priority: Major
>
> The Avro specification does not include examples on how to apply the
> "decimal" or "duration" logical type to a "fixed" type. The implementations
> disagree on what the correct JSON structure is.
> The C++, Java, Python, and Ruby libraries expect the properties of the
> "fixed" type to be in the same JSON object as the properties of the logical
> type:
> {code:JSON}
> {
> "type": "fixed",
> "name": "test.FixedDecimal",
> "size": 8,
> "logicalType": "decimal",
> "precision": 18,
> "scale": 4
> }
> {code}
> The C# and Rust libraries instead expect a nested JSON object for the "fixed"
> type:
> {code:JSON}
> {
> "type": {
> "type": "fixed",
> "name": "test.Fixed8",
> "size": 8
> },
> "logicalType": "decimal",
> "precision": 18,
> "scale": 4
> }
> {code}
> Schemas using types like this are then not interoperable between languages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
