Re: Client side issues with implementing new Collections support in 1.2

> 1. There does not seem to be a notion of a reflexive o.a.c.cql.jdbc.* class > for the new collection classes in o.a.c.db.marshall. Is that intentional or > was that to be "left to be implemented student", which for me is now. I am > trying to make sure I understand to broader design so I do no

Re: Client side issues with implementing new Collections support in 1.2

On Mon, Aug 6, 2012 at 4:49 AM, Sylvain Lebresne wrote: >> 2. JSON does not have a rich enough vocabulary to imply all of the CQL types >> without this additional information. > > JSON really just was a kind of first try, because it made it easy to > test the collection code. CASSANDRA-4453 bring

Re: Client side issues with implementing new Collections support in 1.2

On Mon, Aug 6, 2012 at 10:15 AM, Jonathan Ellis wrote: > That said, it should still be possible to decode correctly by using > the type information from CqlMetadata.value_types. Hmm, apparently we only send "set", not "set". Probably a bug, but maybe it will be simpler to just switch to a more t

Re: Client side issues with implementing new Collections support in 1.2

If the data type comes across in the "generic" part of the type name in the metadata, that should be enough for the client side to do its job. (i.e. ListType or MapType ) I'm happy to change the way to access the compose/decompose fucnctions and handle the JDBC specific stuff based on Type name an

Build failed in Jenkins: Cassandra-quick #1053

See -- [...truncated 388 lines...] [junit] Testsuite: org.apache.cassandra.io.BloomFilterTrackerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.69 sec [junit] [junit] T