[ 
https://issues.apache.org/jira/browse/AVRO-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Doug Cutting updated AVRO-248:
------------------------------

    Fix Version/s:     (was: 1.3.0)

> make unions a named type
> ------------------------
>
>                 Key: AVRO-248
>                 URL: https://issues.apache.org/jira/browse/AVRO-248
>             Project: Avro
>          Issue Type: New Feature
>          Components: spec
>            Reporter: Doug Cutting
>
> Unions are currently anonymous.  However it might be convenient if they were 
> named.  In particular:
>  - when code is generated for a union, a class could be generated that 
> includes an enum indicating which branch of the union is taken, e.g., a union 
> of string and int named Foo might cause a Java class like {code}
> public class Foo {
>   public static enum Type {STRING, INT};
>   private Type type;
>   private Object datum;
>   public Type getType();
>   public String getString() { if (type==STRING) return (String)datum; else 
> throw ... }
>   public void setString(String s) { type = STRING;  datum = s; }
>   ....
> }
> {code} Then Java applications can easily use a switch statement to process 
> union values rather than using instanceof.
>  - when using reflection, an abstract class with a set of concrete 
> implementations can be represented as a union (AVRO-241).  However, if one 
> wishes to create an array one must know the name of the base class, which is 
> not represented in the Avro schema.  One approach would be to add an 
> annotation to the reflected array schema (AVRO-242) noting the base class.  
> But if the union itself were named, that could name the base class.  This 
> would also make reflected protocol interfaces more consise, since the base 
> class name could be used in parameters return types and fields.
>  - Generalizing the above: Avro lacks class inheritance, unions are a way to 
> model inheritance, and this model is more useful if the union is named.
> This would be an incompatible change to schemas.  If we go this way, we 
> should probably rename 1.3 to 2.0.  Note that AVRO-160 proposes an 
> incompatible change to data file formats, which may also force a major 
> release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to