I view this as a current implementation limitation…
which we eliminated in our avro fork by adding the ability to map a arbitrary
string value to a symbol like:
@stringSymbols({“MY_SYMB”: “MY NON ID COMPLIANT VALUE"})
enum MyEnum {
A, B, MY_SYMB
}
there is probably other ways to “resolve’ this...
—Z
> On May 30, 2018, at 9:53 AM, Michael A. Smith <mich...@smith-li.com> wrote:
>
> Hi, we recently ran into AVRO-2174 in the sense that we were using Python,
> and had enums with spaces in some symbols. Now have to do an integration with
> a Java avro system, and have to make some hard choices because Java won't
> accept our enums.
>
> It would help me make some of these choices if I understood if there is a
> technical motivation for not allowing enum symbols to be more arbitrary
> strings. I have read AVRO-1725, but IIUC the decision was made to have the
> spec follow the Java behavior (introducing this break with other
> implementations) starting in 1.8.0.
>
> So, digging deeper, does the data or encoding need this behavior? I'm
> thinking along these lines:
>
> - Are we expected to only use the enum symbols to refer to other names
> defined in the schema?
> - Do spaceless strings lend themselves to a more compact binary encoding?
>
