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