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<timestamp> or MapType<int,boolean> )
I'm happy to change the way to access the compose/decompose fucnctions and handle the JDBC specific stuff based on Type name and not have a Jdbc specific set of methods. Just commit in trunk and we will get going. On Mon, Aug 6, 2012 at 11:20 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > On Mon, Aug 6, 2012 at 10:15 AM, Jonathan Ellis <jbel...@gmail.com> 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<int>". Probably a bug, > but maybe it will be simpler to just switch to a more type-aware > encoding as Sylvain suggested. > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com >
