For some other use cases, allowing all intrinsic simple types to be keys would be useful in the future too. This would make Hive's schema system map column type directly fit into Avro, for example.
But as AVRO-9 points out, this would be problematic in many scripting languages that only support string dictionaries. Complex types as keys is problematic and IMO should be avoided. Avro 2.0 perhaps? In the meantime I'm serializing such data as an array of k,v tuples and the client object API deals with providing a map interface. After all, that is all that a Map is in avro anyway, syntactic sugar around an array with some type checking. -Scott On Apr 5, 2010, at 1:24 PM, Jeff Hodges wrote: > This would probably be of much benefit to the Cassandra community as > they/we are working on getting their stored data to be keyed by byte > arrays instead of String arrays[1]. Converting back and forth would > less good. > > [1] Relevant ticket: https://issues.apache.org/jira/browse/CASSANDRA-767 > -- > Jeff > > On Mon, Apr 5, 2010 at 1:17 PM, Stu Hood <[email protected]> wrote: >> Hey gang, >> >> I can understand the reasoning behind AVRO-9, but now I need to look for an >> alternative to a 'map' that will allow me to store an association of bytes >> keys to values. >> >> Is there a recommended pattern to store this structure, or is "list of >> (key,value) tuples" the best option? >> >> Thanks much, >> >> Stu Hood >> @stuhood >> Architecture Software Developer >> Email & Apps Division, Rackspace Hosting >> >>
