Add variant_access_derive to the enums generated from union types

[batconjurer]

Recently, this crate added support for Avro union types (hooray!), but was forced to create enums with computer generated names and computer generated field names and it is not clear how to avoid that. There are unfortunately a few downsides to that.

• Types are created whose names are not in the input Avro schemas. This means users have to look into the generated code (which may be substantial in size), to find the names of the types they wish to use.

• Type and fields names can be long an unwieldy. This means that users will have to put up with a constantly typing out these names. In the best case, the define a type alias somewhere, in the worst case, they might modify the generated code.

  • If this crate ever decides to change its naming convention, the newly generated types will likely stop working with end users' old code which depended on the old type names.

  To address this, I've been working on a crate called variant_access which allows interaction with Rust enums in a way that avoids specifically writing out the type name. It is modeled on the C++ API for std::variant. This can be derived using a macro, but use by the end user will also require them to use the variant_access_traits crate. For this reason, I've included this as an opt-in feature.

  I have included an example of an input avro schema (that I stole from one of the unit tests), and some code interacting with the generated types, both with and without the variant_access_traits.

  The input schema:

  {
  "type": "record",
  "name": "Contact",
  "namespace": "com.test",
  "fields": [{
  "name": "extra",
  "type": "map",
  "values" : [ "null", "string", "long", "double", "boolean" ]
  }]
  }

  The generate code:

  
  /// Auto-generated type for unnamed Avro union variants.
  #[derive(Debug, PartialEq, Clone, serde::Deserialize, serde::Serialize, variant_access_derive::VariantAccess)]
  pub enum UnionStringLongDoubleBoolean {
  String(String),
  Long(i64),
  Double(f64),
  Boolean(bool),
  }

[serde(default)]

[derive(Debug, PartialEq, Clone, serde::Deserialize, serde::Serialize)]

pub struct Contact { pub extra: ::std::collections::HashMap<String, Option>, }

impl Default for Contact { fn default() -> Contact { Contact { extra: ::std::collections::HashMap::new(), } } }

And a side-by-side comparison of using / not using `variant_access_traits` 
```rust
mod contact;
use variant_access_traits::*;
use crate::contact::*;

fn main() {

    //without variant_access
    let mut contact = Contact::default();
    contact.extra.insert(String::from("John"),
                         Some(UnionStringLongDoubleBoolean::String(String::from("Colleagues"))));
    if let Some(value) = contact.extra.get_mut("John").unwrap() {
        if let UnionStringLongDoubleBoolean::String(inner) = value {
            println!("{}", inner);
            *inner = String::from("Ex-colleague");
            println!("{:?}", value);
        } else {
            println!("Well, that was unexpected");
        }
    }

    // with variant_access
    let mut contact = Contact::default();
    contact.extra.insert(String::from("John"),
                         Some(create_variant_from(String::from("Colleague"))));
    if let Some(value) = contact.extra.get_mut("John").unwrap() {
        if let Ok(true) = value.contains_variant::<String>() {
            let inner: &mut String = value.get_variant_mut().expect("Uh oh");
            println!("{}", inner);
            *inner = String::from("Ex-colleague");
            println!("{:?}", value)
        } else {
            println!("Well, that was unexpected!");
        }
    }
}

[lerouxrgd]

Thank you for this feature.

However I'd see the implementation more like this:

• Add a boolean flag use_variant_access to Templater, defaults to false
• If the flag is set, to pass it to UNION_TEMPLATE
  • Something like: #[derive(Debug, PartialEq, Clone, serde::Deserialize, serde::Serialize{%- if use_variant_access %},variant_access_derive::VariantAccess{%- endif %})]
• Set use_variant_access through GeneratorBuilder (like precision and nullable options)
• Add it to the cli too (with docopt)

Also, do you need to add use variant_access_traits::*; in the generated file ? I think it is only necessary in your main (or where you use the actual generated code) isn't it ?

Besides, there is no need for a cargo feature.

Let me know if you want to give the it a try with the above plan, otherwise I should be able to do it this week.

[batconjurer]

I have made the above changes. Please double check the docopt string to make sure it is clear. I also needed to make a quick patch to the variant_access crate so that the use variant_access_traits::*; line was not necessary in the generated code. So this means that anyone using this feature should use variant_access version 0.3.1 or later.

[lerouxrgd]

Perfect, thank you ! This has been released in 0.9.1.