I really with I could thrift slice a non compact table and decode it with user space tools :)
On Thu, Mar 6, 2014 at 9:22 AM, Theo Hultberg <t...@iconara.net> wrote: > what I meant by step backwards is that the user defined types feature has > been without adding it to the CQL protocol. it's not a protocol feature, > and hasn't even got a spec. > > T# > > > On Thu, Mar 6, 2014 at 2:58 PM, Edward Capriolo <edlinuxg...@gmail.com > >wrote: > > > its not a step backwards though the emphasis was to remove burden from > the > > client developers. The value of a cassandra column could be 2GB but you > > were limited by a thrift frame. Now with the native protocol you can now > > throw huge objects in a column users can find new uses to use/break the > > database. Before you had to break that up across columns. > > > > > > On Thu, Mar 6, 2014 at 1:33 AM, Theo Hultberg <t...@iconara.net> wrote: > > > > > I agree, it feels like a step backwards for the CQL protocol. > > > > > > T# > > > > > > > > > On Wed, Mar 5, 2014 at 8:10 PM, Edward Capriolo <edlinuxg...@gmail.com > > > >wrote: > > > > > > > Somewhat of an aside. But wasn't issues with client serialization > > issues > > > > one of the reasons to get away from thrift? It seems like asking > client > > > > language to decode complex objects recreates the problem only with 1 > > > degree > > > > more complexity. > > > > > > > > > > > > On Wed, Mar 5, 2014 at 1:55 PM, Theo Hultberg <t...@iconara.net> > > wrote: > > > > > > > > > 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/> > > > > > > > > > > > > > > > > > > > > >