[
https://issues.apache.org/jira/browse/AVRO-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699486#comment-17699486
]
ASF subversion and git services commented on AVRO-3646:
-------------------------------------------------------
Commit 537025c0398313363e811e3e0258a433e8ee0d81 in avro's branch
refs/heads/branch-1.11 from Martin Grigorov
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=537025c03 ]
AVRO-3683: [Rust] Read/Write with multiple schemas (#2014)
* AVRO-3683: Add support for using multiple schemata for resolve/validate/write
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: WIP
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: WIP compiles
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: WIP compiles and all tests pass
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: WIP Add support for reading
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: WIP
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: WIP
Use a main schema and pass all other schemata for resolution.
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: Formatting
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: WIP
Add support for multiple schemata in Reader/Writer APIs
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3646: Formatting
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: Use Vec instead of slice reference for schemata
It is much easier to deal with.
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: Fix the resolving of the writer schema when reading an Avro file
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
* AVRO-3683: Cleaup
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
---------
Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
(cherry picked from commit b8b83b72f7184cf1b388fc20331d11eabbd93e06)
> Serialization / deserialization for enum with mixed variants (with and
> without data)
> ------------------------------------------------------------------------------------
>
> Key: AVRO-3646
> URL: https://issues.apache.org/jira/browse/AVRO-3646
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
> Reporter: Lucas Javaudin
> Assignee: Martin Tzvetanov Grigorov
> Priority: Major
> Labels: pull-request-available, rust
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> Consider the following example of what I call an "enum with mixed variants":
> {code:java}
> enum MixedExternalEnum {
> Val1,
> Val2(f32),
> } {code}
> For the two variants, this enum can be properly serialized to and
> deserialized from a {{types::Value}} (using {{ser::to_value}} and
> {{{}de::from_value{}}}). The problem is that the way they are represented as
> a \{{types::Value}} cannot be represented using an Avro Schema.
> The serialized version of {{MixedExternalEnum::Val1}} is
> {code:java}
> Value::Record(vec![("a".to_owned(), Value::Enum(0, "Val1".to_owned()))])
> {code}
> while the serialized version of {{MixedExternalEnum::Val2(0.0)}} is
> {code:java}
> Value::Record(vec![(
> "a".to_owned(),
> Value::Record(vec![
> ("type".to_owned(), Value::Enum(1, "Val2".to_owned())),
> (
> "value".to_owned(),
> Value::Union(1, Box::new(Value::Float(0.0))),
> ),
> ]),
> )])
> {code}
> As far as I know, there is no Avro Schema compatible with both possible
> values.
> One solution I can think of is to change the serialization of
> {{MixedExternalEnum::Val1}} to
> {code:java}
> Value::Record(vec![(
> "a".to_owned(),
> Value::Record(vec![
> ("type".to_owned(), Value::Enum(0, "Val1".to_owned())),
> (
> "value".to_owned(),
> Value::Union(0, Box::new(Value::Null)),
> ),
> ]),
> )])
> {code}
>
> A workaround is to replace {{Val1}} by {{Val1(())}} in the enum definition
> (see AVRO-3645) but this can have undesirable effects for other parts of the
> code.
>
> Then, it's another story for adjacently tagged, internally tagged and
> untagged enum...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
