Please do. I too am working at a driver implementation and would be delighted to be spared the research. On Feb 25, 2014 11:29 AM, "Theo Hultberg" <t...@iconara.net> wrote:
> 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 >> >> >> >
