;
Sent: Friday, November 5, 2010 8:44am
To: client-dev@cassandra.apache.org
Subject: Re: Calling all library maintainers
On Fri, 2010-11-05 at 02:43 -0500, Stu Hood wrote:
> > Java you serialize a type to a byte[] whereas with the query
> > language you'd serialize to a string t
o: client-dev@cassandra.apache.org
Subject: Re: Calling all library maintainers
On Fri, 2010-11-05 at 02:43 -0500, Stu Hood wrote:
> > Java you serialize a type to a byte[] whereas with the query
> > language you'd serialize to a string term
> >
> The "serializing to a byte
On Fri, Nov 5, 2010 at 11:40 AM, Gary Dusbabek wrote:
>>
>> I still think the query language is a good idea but I have one
>> negative point about it.
>>
>> One of the selling point about a simple data model and access language
>> was that there were never issues where a query planner "refused" to
>
> I still think the query language is a good idea but I have one
> negative point about it.
>
> One of the selling point about a simple data model and access language
> was that there were never issues where a query planner "refused" to do
> the query the "optimal way" the user desired. For examp
th of which only need to be implemented once, of course.
>
>> -Original Message-
>> From: "Eric Evans"
>> Sent: Thursday, November 4, 2010 2:59pm
>> To: client-dev@cassandra.apache.org
>> Subject: Re: Calling all library maintainers
>>
>&
ords, in Python it becomes:
import struct; struct.pack('>d', val)
versus
str(val)
Both of which only need to be implemented once, of course.
> -Original Message-
> From: "Eric Evans"
> Sent: Thursday, November 4, 2010 2:59pm
> To: client-dev@cassan
2:59pm
To: client-dev@cassandra.apache.org
Subject: Re: Calling all library maintainers
On Thu, 2010-11-04 at 21:28 +0200, Ran Tavory wrote:
> A QL can shield clients from a class of changes, but OTOH will make
> clients have to compose the query strings, where with type safe
> libraries t
I'm also all in for a query language. There has been some excellent
reasons already posted, but I have another good reason why a QL would
be better: maintaining the cluster.
Due to 0.7 the Thrift API has now multiple structures and functions to:
- define indexes
- create/drop/rename new column f
On Thu, Nov 4, 2010 at 2:28 PM, Ran Tavory wrote:
> One small question, does this language tunnel through avro or thrift calls?
> (Is >>> conn.execute() an avro or thrift call)
Avro. See test/system/test_cql.py
-Brandon
A QL can shield clients from a class of changes, but OTOH will make clients
have to compose the query strings, where with type safe libraries this job
is somewhat easier. IMO in the near term introducing a query language will
make client dev somewhat harder b/c of the (somewhat negligible) work of
On Thu, 2010-11-04 at 09:30 -0700, Dave Viner wrote:
> 1. How does replacing thrift/avro with a SQL-inspired query language make
> the server more stable? As a client, I still need to connect via something,
> and that something will make something like an RPC call to the server. In
> traditional
A few quick thoughts and questions.
1. How does replacing thrift/avro with a SQL-inspired query language make
the server more stable? As a client, I still need to connect via something,
and that something will make something like an RPC call to the server. In
traditional rdbms-es, this is wrappe
Some of you might already be aware, but I recently proposed a query
language as an alternative to (or full replacement for) the Thrift/Avro
RPC interfaces.
http://article.gmane.org/gmane.comp.db.cassandra.devel/2370
For me, this isn't so much about making the raw Cassandra interface
"easier", as
13 matches
Mail list logo
