Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1257)
Subject: Re: Document storage
From: Drew Kutcharian <drew@venarc.com>
In-Reply-To: 
 <CAENxBwx7BddEs2_vhENBq+XnywFo7dZSykxipudN51Vw-Z0s6A@mail.gmail.com>
Date: Thu, 29 Mar 2012 11:07:12 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6BC34026-E891-4689-AB1E-A579C047C3BB@venarc.com>
References: 
 <CAH3cagMWrgptNtBLSQLrpmJFZFhoN64eqg5iaBp5Eu6=_Sx9aA@mail.gmail.com>
 <CAHe1ogtOCFKrUcByV=7xfrL9qSVQfwBzhA75nQir+jPdw0D_kw@mail.gmail.com>
 <CAH3cagN8AE4wLk=fKrn=PFuvbiJte6AUFZZ2zHXFXXKwAywAaQ@mail.gmail.com>
 <CAENxBwx7BddEs2_vhENBq+XnywFo7dZSykxipudN51Vw-Z0s6A@mail.gmail.com>
To: dev@cassandra.apache.org

I agree with Edward here, the simpler we keep the core the better. I =
think all the ser/deser and conversions should happen on the client =
side.

-- Drew


On Mar 29, 2012, at 8:36 AM, Edward Capriolo wrote:

> 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?
>=20
>=20
> On Thu, Mar 29, 2012 at 11:23 AM, Ben McCann <ben@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.
>>=20
>>=20
>> On Thu, Mar 29, 2012 at 8:21 AM, Tyler Patterson =
<tpatterson@datastax.com>wrote:
>>=20
>>>>=20
>>>>=20
>>>> Would there be interest in adding a JsonType?
>>>=20
>>>=20
>>> 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?
>>>=20