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/>
>

Reply via email to