[
https://issues.apache.org/jira/browse/AVRO-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Morgan Parry updated AVRO-3770:
-------------------------------
Description:
Both of these classes will read from an aliased value correctly but then will
go on to try and insert a default value reader, because they're also still
looking for the new name in the writer schema.
For example, with a field like
{code:json}
{
"name": "i",
"type": "int",
"aliases": "j"
}
{code}
and some old serialised data that was still writing the field {{j}} instead,
the readers will read that {{j}} value into {{i}} (as expected) but then also
add some fallback handling for the 'missing' {{i}} field. This is due to the
following loop in {{PreresolvingDatumReader}}, for example:
{code:c#}
foreach (Field rf in readerSchema)
{
if (writerSchema.Contains(rf.Name)) continue;
{code}
That condition isn't sufficient in the case of aliasing.
I believe it's also the case that {{SpecificDefaultReader}} doesn't handle
aliases at all, since it uses {{TryGetField()}} rather than
{{TryGetFieldAlias()}}.
was:
Both of these classes will read from an aliased value correctly but then will
go on to try and insert a default value reader, because they're also still
looking for the new name in the writer schema.
For example, with a field like
{code:json}
{
"name": "i",
"type": "int",
"aliases": "j"
}
{code}
and some old serialised data that was still writing the field {{j}} instead,
the readers will read that {{j}} value into {{i}} (as expected) but then also
add some fallback handling for the 'missing' {{i}} field. This is due to the
following loop in {{PreresolvingDatumReader}}, for example:
{code:csharp}
foreach (Field rf in readerSchema)
{
if (writerSchema.Contains(rf.Name)) continue;
{code}
That condition isn't sufficient in the case of aliasing.
I believe it's also the case that {{SpecificDefaultReader}} doesn't handle
aliases at all, since it uses {{TryGetField()}} rather than
{{TryGetFieldAlias()}}.
> SpecificDefaultReader and PreresolvingDatumReader don't handle aliases
> properly
> -------------------------------------------------------------------------------
>
> Key: AVRO-3770
> URL: https://issues.apache.org/jira/browse/AVRO-3770
> Project: Apache Avro
> Issue Type: Bug
> Components: csharp
> Affects Versions: 1.11.1
> Reporter: Morgan Parry
> Priority: Major
>
> Both of these classes will read from an aliased value correctly but then will
> go on to try and insert a default value reader, because they're also still
> looking for the new name in the writer schema.
> For example, with a field like
> {code:json}
> {
> "name": "i",
> "type": "int",
> "aliases": "j"
> }
> {code}
> and some old serialised data that was still writing the field {{j}} instead,
> the readers will read that {{j}} value into {{i}} (as expected) but then also
> add some fallback handling for the 'missing' {{i}} field. This is due to the
> following loop in {{PreresolvingDatumReader}}, for example:
> {code:c#}
> foreach (Field rf in readerSchema)
> {
> if (writerSchema.Contains(rf.Name)) continue;
> {code}
> That condition isn't sufficient in the case of aliasing.
> I believe it's also the case that {{SpecificDefaultReader}} doesn't handle
> aliases at all, since it uses {{TryGetField()}} rather than
> {{TryGetFieldAlias()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
