thanks for the high level description of the format, I'll see if I can make a stab at implementing support for custom types now.
and maybe I should take all of the reverse engineering I've done of the type encoding and decoding and send a pull request for the protocol spec, or write an appendix. T# On Tue, Feb 25, 2014 at 12:10 PM, Sylvain Lebresne <sylv...@datastax.com>wrote: > >> Is there any documentation on how CQL clients should handle the new user >> defined types coming in 2.1? There's nothing in the protocol specification >> on how to handle custom types as far as I can see. >> > > Can't say there is much documentation so far for that. As for the spec, it > was written in a time where user defined types didn't existed and so as far > as the protocol is concerned so far, user defined types are handled by the > protocol as a "custom type", i.e the full internal class is returned. And > so ... > > >> >> For example, I tried creating the "address" type from the description of >> CASSANDRA-5590, and this is how its metadata looks (the metadata for a >> query contains a column with a custom type and this is the description of >> it): >> >> >> org.apache.cassandra.db.marshal.UserType(user_defined_types,61646472657373,737472656574:org.apache.cassandra.db.marshal.UTF8Type,63697479:org.apache.cassandra.db.marshal.UTF8Type,7a69705f636f6465:org.apache.cassandra.db.marshal.Int32Type,70686f6e6573:org.apache.cassandra.db.marshal.SetType(org.apache.cassandra.db.marshal.UTF8Type)) >> >> Is the client supposed to parse that description, and in that case how? >> > > ... yes, for now you're supposed to parse that description. Which is not > really much documented outside of looking up the Cassandra code, but I can > tell you that the first parameter of the UserType is the keyspace name the > type has been defined in, the second is the type name hex encoded, and the > rest is list of fields and their type. Each field name is hex encoded and > separated from it's type by ':'. And that's about it. > > We will introduce much shorted definitions in the next iteration of the > native protocol, but it's yet unclear when that will happen. > > -- > Sylvain > > >
