cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From user 01 <>
Subject Re: Migrate from Hector(unmaintained) to Astyanax for Cassandra 2.0.7, (delaying thrift to CQL migration plan) ?
Date Wed, 28 May 2014 20:47:29 GMT
Personally I like thrift based APIs more than the CQL based ones, as it is
more intuitive & easy to understand relating it to cassandra's internal
storage design. CQL to deal with dynamic columns/wide rows is really not
intuitive or easily graspable as of now.

On Thu, May 29, 2014 at 12:32 AM, Peter Lin <> wrote:

> I don't think anyone can predict the future.
> CQL is nice, but there's still lots of room for improvement. There's a
> reason why projects like spark, shark, impala and presto exist. I would
> expect something to replace CQL in the future as things evolve. Plus, the
> type safety that thrift clients shouldn't be over looked. I love SQL and
> the power it gives developers, but type safety isn't one of the strengths.
> That's just the nature of SQL and "sql inspired" languages.
> for me, Cassandra's ability to straddle strong schema like RDB and no
> schema like document databases is what sets it apart. I love that it covers
> static schema, dynamic schema and no schema better than using three
> different databases( RDB + object DB + document DB). plus, I like being to
> control exactly how I store data with Hector and thrift. I also like
> writing tools that take advantage of generics and strong typing.
> as much as some people hate thrift, it has benefits. It would be a shame
> to ignore the lessons history teaches us. There's a reason why things like
> LINQ came into existence.
> On Wed, May 28, 2014 at 2:44 PM, Robert Coli <> wrote:
>> On Wed, May 28, 2014 at 7:19 AM, user 01 <> wrote:
>>> 2. *What is the future of thrift based APIs  *(& specifically Astyanax)
>>> ?
>> Logic suggests that the thrift based API will ultimately be removed, at
>> the time in the future when the cost of working around its moribund area of
>> the code exceeds the controversy involved in deprecating it.
>> This will probably not happen for quite some time, but my view is that it
>> must happen eventually. If it *doesn't* eventually happen, my view is that
>> the project will have made a serious error in creating a database with two
>> different, non-pluggable APIs.
>> =Rob

View raw message