Re: How should clients handle the user defined types in 2.1?

[Tyler Hobbs]

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/

Re: How should clients handle the user defined types in 2.1?

[Theo Hultberg]

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?

T#


On Sat, Mar 1, 2014 at 1:12 AM, Mikhail Stepura mikhail.step...@outlook.com
 wrote:

 Hi Theo,

 Take a look at https://github.com/datastax/python-driver/blob/master/
 cassandra/cqltypes.py#L111



 On 2/25/14, 23:09, Theo Hultberg wrote:

 thanks mikhail.

 it bothers me a bit that there is the possibility of arbitrarily deeply
 nested types (it's great for usability, but a headache for me as a driver
 implementer). it feels like just throwing a couple of regexes at this is
 the wrong solution, the string has too much structure and hierarchy for
 that and I think that not doing it with a proper parser will cause trouble
 in the future. and then trying to use the parsed type structure to
 properly
 encode something that the user wants to store will be very complex. kind
 of
 like having to implement a whole orm. it's going to be a challenge.

 I see that you took the parser route in the python driver so I can at
 least
 get some inspiration from there. what do you do when the user passes an
 object in a custom type field and that object doesn't look like the type
 at
 all?

 T#


 On Tue, Feb 25, 2014 at 8:16 PM, Mikhail Stepura 
 mikhail.step...@outlook.com wrote:

  I just realized that your driver returns fields' names in the type itself
 (which unfortunately is not the case with python driver) so you don't
 need
 step #3.

 -M



 On 2/25/14, 10:42, Mikhail Stepura wrote:

  The driver shall parse that.
 I'm not sure if there is a doc for that, but here is what I did for
 CQLSH

 1. UserType is a CompositeType, where 1s subtype is a KS name, and 2nd
 is hex-encoded name of the type
 2. Remainder of subtypes are types of Usertype's columns. So you can
 easily decode *values* for fields
 3. Information about field *names* is stored in system.schema_usertypes
 table
 4. The driver has to combine pieces 1-3 and create a new class/type for
 a user. It was easy in Python, I guess it should be easy in Ruby as well

 -M


 On 2/22/14, 12:29, Theo Hultberg wrote:

  Hi,

 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 understand.

 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? I
 could probably figure it out but it would be great if someone could
 point
 me to the right docs.

 yours,
 Theo (author of cql-rb, the Ruby driver)