I agree with Edward here. We use Thrift too and we haven't really found a good
enough reason to move to CQL3.
-- Drew
On Dec 1, 2012, at 10:24 AM, Edward Capriolo wrote:
> I do not understand why everyone wants to force this issue on removing
> thrift. If cql, cql sparse tables and the new tra
client nodes where there is plenty
idle CPU time
2. Saving network bandwidth since I'm sending over a compressed byte[]
-- Drew
On Mar 29, 2012, at 11:16 AM, Jonathan Ellis wrote:
> On Thu, Mar 29, 2012 at 1:11 PM, Drew Kutcharian wrote:
>>> I think this is a much bette
> I think this is a much better approach because that gives you the
> ability to update or retrieve just parts of objects efficiently,
> rather than making column values just blobs with a bunch of special
> case logic to introspect them. Which feels like a big step backwards
> to me.
Unless your
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 e
way would be good and I voted for it). Btw, any reason you
> compress it with Snappy yourself instead of just setting sstable_compression
> to
> SnappyCompressor<http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-compression>and
> letting Cassandra do that part?
>
I'm actually doing something almost the same. I serialize my objects into
byte[] using Jackson's SMILE format, then compress it using Snappy then store
the byte[] in Cassandra. I actually created a simple Cassandra Type for this
but I hit a wall with cassandra-cli:
https://issues.apache.org/jir
I think there are couple of different ideas here at play
1) Time to release
2) Quality of the release
IMO, the issue that effects most people is the quality of the release. So when
someone says that we should slow down the release cycles, I think what they
mean is that we should spend more tim
