"According to writer schema a zero will be encoded. However when deserialized using the aforementioned reader schema the datum will correspond to HEARTS since the order of symbols has changed in the reader schema and HEARTS is the first."
Have you observed this problem - do you have a code snippet for how you are reading? The schemas are indeed compatible despite the re-ordering, and you should get "SPADES" back when you read assuming Avro knows about both the writer and the reader schema (and thus can correctly interpret "zero') On Sep 26, 2013, at 7:57 AM, Youssef Hatem <[email protected]> wrote: > Hello, > > According to Avro Standard 1.7.5 enums match when names match and all writer > symbols exist in reader schema. > > According to this definition the following writer schema: > { "type": "enum", "name":"Suit","symbols":["SPADES", "HEARTS", "DIAMONDS", > "CLUBS"]} > matches this reader schema: > { "type": "enum", "name":"Suit","symbols":["HEARTS", "SPADES", "DIAMONDS", > "CLUBS"]} > > However this can lead to semantical problems. Assume I have the following > datum: > Suit suit = SPADES > > According to writer schema a zero will be encoded. However when deserialized > using the aforementioned reader schema the datum will correspond to HEARTS > since the order of symbols has changed in the reader schema and HEARTS is the > first. > > My question is, why the standard doesn't explicitly add another constraint > for matching enums like the order of elements must be preserved, or is it > implied? > > Best regards, > Youssef Hatem
smime.p7s
Description: S/MIME cryptographic signature
