The issue with these super complex types is to do anything useful with them you would either need scanners or co processors. As its stands right now complex data like json is fairly opaque to Cassandra. Getting cassandra to natively speak protobuffs or whatever flavor of the week serialization framework is hip right now we make the codebase very large. How is that field sorted? How is it indexed? This is starting to go very far against the schema-less nosql grain. Where does this end up users wanting to store binary XML index it and feed cassandra XPath queries?
On Thu, Mar 29, 2012 at 11:23 AM, Ben McCann <b...@benmccann.com> wrote: > Creating materialized paths may well be a possible solution. If that were > the solution the community were to agree upon then I would like it to be a > standardized and well-documented best practice. I asked how to store a > list of values on the user > list<http://www.mail-archive.com/user@cassandra.apache.org/msg21274.html> > and > no one suggested ["fieldName", <TimeUUID>]: "fieldValue". It would be a > huge pain right now to create materialized paths like this for each of my > objects, so client library support would definitely be needed. And the > client libraries should agree. If Astyanax and lazyboy both add support > for materialized path and I write an object to Cassandra with Astyanax, > then I should be able to read it back with lazyboy. The benefit of using > JSON/SMILE is that it's very clear that there's exactly one way to > serialize and deserialize the data and it's very easy. It's not clear to > me that this is true using materialized paths. > > > On Thu, Mar 29, 2012 at 8:21 AM, Tyler Patterson > <tpatter...@datastax.com>wrote: > >> > >> > >> > Would there be interest in adding a JsonType? >> >> >> What about checking that data inserted into a JsonType is valid JSON? How >> would you do it, and would the overhead be something we are concerned >> about, especially if the JSON string is large? >>
