If you're using the code generation, it's conceivable to special cases 1, 2, 4, and 8-byte fixed types to be represented (in the generated code) with byte, short, int, and long. The code generator would then do something different in the rare case of union(long, fixed-8) (and the like). I've seen 64-bit constants with uniform distributions show up a lot as IDs that were generated via hasing.
Doing special-casing doesn't seem appetizing right now, though, so I'd vote to wait and see how painful the current API is. -- Philip On Fri, Oct 23, 2009 at 10:44 AM, Doug Cutting <[email protected]> wrote: > Mr Fish wrote: > >> Anybody thought of supporting fixed int and fixed long? The use case would >> be where you want to modify identifiers in steams of messages. Eg. stamp a >> id on a transaction for example. I could use fixed 8 or fixed 4, but a >> long >> or int is neater. >> > > The serialized form of {"type": "fixed", "size" 8} is identical to what you > want. So the question is one of APIs. You'd presumably like an API where > you map this to your programming languages long type. That's certainly > possible. > > However, the way unions are currently implemented in Java, we need to be > able to, given an object's runtime type, determine its Avro type. So, > assuming you're interested in a Java API, how would you represent these? > How would you, e.g., write a union of fixed-8 and long, when passed a > java.lang.Long? Unless we start representing unions in Java with an > explicit object, you'd need to use a different Java representation for > Avro's long type, e.g., avro.util.Long or somesuch. That's possible, but > would make a lot of other things awkward. Or we could switch to > representing unions explicitly, which would make a lot of other things > awkward. > > For your example, an over-written ID stamp, how awkward is it to use a byte > array to represent this? It doesn't seem that un-natural to me. > > Doug >
