cassandra-client-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler Hobbs <>
Subject Re: How should clients handle the user defined types in 2.1?
Date Tue, 04 Mar 2014 20:28:17 GMT
On Sat, Mar 1, 2014 at 5:01 AM, Theo Hultberg <> wrote:

> Mikhail, thanks, but I meant the reverse of that. Say the user creates a
> prepared statement where one of the columns is a custom type, how do you
> serialize the arguments to the prepared statement? Do you accept anything
> and let C* complain, or do you make a best effort to shoehorn the object
> the user passed into something that looks like the custom type?

Just to be clear, by "custom type", you still mean a user-defined type,

At least in the python driver, it's treated the same as any other
(parametrized) type.  For each Cassandra type (UTF8Type, Int32Type, etc),
the driver will accept values of one or more types.  If any of the subtypes
don't match this, the driver will raise an exception.

If you're actually talking about custom types and not user-defined types,
I'll explain what the python driver does.  If the typestring (e.g.
org.apache.cassandra.db.marshal.MyType) isn't recognized, the driver will
expect a binary string that it can pass directly to Cassandra for values of
that type.  If the user wants to add driver-level support for it (to enable
converting a python object to a binary string and vice-versa), they can
subclass cassandra.cqltypes.CassandraType and define a serialize() and
deserialize() method.  The only condition is that the python classname must
match the typestring from cassandra, so for
org.apache.cassandra.db.marshal.MyType, the user will create a
MyType(CassandraType) class.

Tyler Hobbs
DataStax <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message