thanks! yeah, I meant user defined types, but thanks for the description of general custom types too, it's good to know.
T# On Tue, Mar 4, 2014 at 9:28 PM, Tyler Hobbs <ty...@datastax.com> wrote: > On Sat, Mar 1, 2014 at 5:01 AM, Theo Hultberg <t...@iconara.net> 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, > correct? > > 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 <http://datastax.com/> >