incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Theo Hultberg <>
Subject Re: How should clients handle the user defined types in 2.1?
Date Tue, 25 Feb 2014 16:29:25 GMT
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.


On Tue, Feb 25, 2014 at 12:10 PM, Sylvain Lebresne <>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

View raw message