[ 
https://issues.apache.org/jira/browse/AVRO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724231#comment-17724231
 ] 

Martin Tzvetanov Grigorov commented on AVRO-3759:
-------------------------------------------------

Please expand more on "That would significantly help users, as we can't use 
enum variants as types in Rust".

I made some of the changes but so far I don't see the benefit. Just the 
opposite I need to type more for each match arm, e.g.:

{code}

 
{code:java}
-                Schema::Record { name, fields, .. } => {
+                Schema::Record(RecordSchema { name, fields, .. } ) => { {code}
 

> [Rust] Schema types inconsistency
> ---------------------------------
>
>                 Key: AVRO-3759
>                 URL: https://issues.apache.org/jira/browse/AVRO-3759
>             Project: Apache Avro
>          Issue Type: Improvement
>          Components: rust
>            Reporter: Fedor Telnov
>            Priority: Major
>
> That is how Unions and Records are defined in apache-avro Rust crate:
>  
> ```
>     /// A `union` Avro schema.
>     Union(UnionSchema),
>     /// A `record` Avro schema.
>     ///
>     /// The `lookup` table maps field names to their position in the `Vec`
>     /// of `fields`.
>     Record {
>         name: Name,
>         aliases: Aliases,
>         doc: Documentation,
>         fields: Vec<RecordField>,
>         lookup: BTreeMap<String, usize>,
>     },
> ```
>  
> That is inconsistent - one variant is defined with pattern Type(Type) which 
> is VERY convenient(for instance, it allows one to use UnionSchema as type), 
> and the other one(Record) is simply a struct variant, which is not very 
> convenient. My proposition is to hide Record's body in RecordSchema type and 
> use it here - just as you do with union. That would significantly help users, 
> as we can't use enum variants as types in Rust. It can also be done with 
> other schema types as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to