[
https://issues.apache.org/jira/browse/AVRO-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030001#comment-18030001
]
David Neukam edited comment on AVRO-4187 at 10/15/25 8:23 AM:
--------------------------------------------------------------
I identified an issue with this change.
Though being a correct fix, people could currently rely on the buggy behaviour
of having the C# names in the SCHEMA files.
For them, this could be a breaking change.
Another issue is, that the Avro deserializer does not support mapping form Avro
Namespaces to C# namespaces.
The issue is, that the
[ObjectCreator]([https://github.com/apache/avro/blob/main/lang/csharp/src/apache/main/Specific/ObjectCreator.cs])
does not have an extension point to provide the (reverse) namespace mappings.
It searches for the types with the namespaces given in the Avro schema.
By a hacky solution, I could make this work by adding the types to
typeCacheByName via reflection.
I checked the Java implementation and it looks like they also dont support
namespace mapping.
I thend to come to the conclusion, that the avrogen should not have a
--namespace flag as the other Avro tooling does not support namespace mappings
- so we are depending on a bug in the code generation to be able to deserialize
the types again (affecting the contract).
I would suggest deprecating the --namespace flag with that information.
was (Author: JIRAUSER311201):
I identified an issue with this change.
Though being a correct fix, people could currently rely on the buggy behaviour
of having the C# names in the SCHEMA files.
For them, this could be a breaking change.
Another issue is, that the Avro deserializer does not support mapping form Avro
Namespaces to C# namespaces.
The issue is, that the
[ObjectCreator](https://github.com/apache/avro/blob/main/lang/csharp/src/apache/main/Specific/ObjectCreator.cs)
does not have an extension point to provide the (reverse) namespace mappings.
It searches for the types with the namespaces given in the Avro schema.
By a hacky solution, I could make this work by adding the types to
typeCacheByName via reflection.
I checked the Java implementation and it looks like they also dont support
namespace mapping.
I thend to come to the conclusion, that the avrogen should not have a
--namespace flag as the other Avro tooling does not support namespace mappings
- so we are depending on a bug in the code generation to be able to deserialize
the types again (affecting the contract).
I would suggest deprecating the --namespace flag with that information.
> Avrogen (csharp) --namespace causes "SCHEMA" to contain csharp instead of
> avro namespaces leading to the serializer not finding the schema in the
> schema registry
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AVRO-4187
> URL: https://issues.apache.org/jira/browse/AVRO-4187
> Project: Apache Avro
> Issue Type: Bug
> Components: csharp
> Affects Versions: 1.11.1, 1.12.0
> Reporter: David Neukam
> Priority: Major
> Labels: pull-request-available
> Attachments:
> 0001-AVRO-4187-csharp-fix-Avrogen-generated-SCHEMA-contai.patch
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> When using *avrogen* for generating C# models from a schemafile, the
> *--namespace* option doesn't behave as expected.
> When running
> {code:java}
> avrogen -s file.avsc . --namespace my.avro.ns:my.csharp.ns
> {code}
> the namespace within the SCHEMA property of the generated C# files is changed
> to {*}my.csharp.ns{*}, but should be left with value *my.avro.ns.*
>
> This was introduced with the bugfix in AVRO-2883.
>
> Example of expected output ({*}TestModel.cs{*}):
> {code:java}
> namespace my.csharp.ns
> {
> using System;
> using System.Collections.Generic;
> using System.Text;
> using Avro;
> using Avro.Specific;
>
> public partial class TestModel : ISpecificRecord
> {
> public static Schema _SCHEMA =
> Avro.Schema.Parse("{\"type\":\"record\",\"name\":\"TestModel\",\"namespace\":\"my.avro.ns\",\"fields\":[{\"name\":\"e"
> +
>
> "ventType\",\"type\":{\"type\":\"enum\",\"name\":\"EventType\",\"namespace\":\"my.avro.ns\",\"sym"
> +
>
> "bols\":[\"CREATE\",\"UPDATE\",\"DELETE\"]}}]}");
> private my.csharp.ns.EventType _eventType;
> // More generated code
> }
> }
> {code}
>
> Example of *ACTUAL* output ({*}TestModel.cs{*}):
> {code:java}
> namespace my.csharp.ns
> {
> using System;
> using System.Collections.Generic;
> using System.Text;
> using Avro;
> using Avro.Specific;
>
> public partial class TestModel : ISpecificRecord
> {
> public static Schema _SCHEMA =
> Avro.Schema.Parse("{\"type\":\"record\",\"name\":\"TestModel\",\"namespace\":\"my.csharp.ns\",\"fields\":[{\"name\":\"e"
> +
>
> "ventType\",\"type\":{\"type\":\"enum\",\"name\":\"EventType\",\"namespace\":\"my.csharp.ns\",\"sym"
> +
>
> "bols\":[\"CREATE\",\"UPDATE\",\"DELETE\"]}}]}");
> private my.csharp.ns.EventType _eventType;
> // More generated code
> }
> }{code}
>
> This issue is already mentioned in the comments of AVRO-2883:
> {quote}Calling Schema.ToString() on the generated _SCHEMA property will use
> the mapped namespaces. I suspect this could cause
> [Confluent.SchemaRegistry.Serdes.SpecificSerializerImpl<T>.Serialize|https://github.com/confluentinc/confluent-kafka-dotnet/blob/0f44064fd7ff2513e5fb01230f0faab9f9715a64/src/Confluent.SchemaRegistry.Serdes.Avro/SpecificSerializerImpl.cs#L228]
> not to find the schema in the schema registry, if it is configured to
> neither register schemas automatically nor use the latest schema. I'm not
> sure whether their schema registry distinguishes between schemas using
> different namespaces.
> {quote}
> ??[~kniemitalo]??
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
