Re: State Of: CQL

[David Boxenhorn]

There was some opposition to the name CQL due to name conflicts.

May I suggest "Cassquel"? I think it has a nice sound.

On Fri, Mar 18, 2011 at 9:54 PM, Eric Evans  wrote:

>
> With 3 weeks and change until the branch-and-feature-freeze, I thought
> I'd take a few moments to update everyone on the current state of CQL.
>
> Goals and Progress[1]
> -
> The overarching goal of course, is to create a compelling replacement
> for the RPC interface, one that is less baroque, comparable in
> performance, and stable across Cassandra release versions.
>
> The goals for Cassandra 0.8 are to meet or exceed the point of minimum
> usability.  That is to say, a significant number of users/applications
> can make use of it.  I believe we're on track to achieve that.
>
> Already complete:
> * Complete data manipulation (SELECT, UPDATE, DELETE, TRUNCATE ...)
> * Partial DDL, enough to create a schema, (ALTER is missing).
> * Drivers for Python (including Twisted), and Java (JDBC).
> * Language documentation (doc/cql/CQL.html)
>
> Remaining for 0.8:
> * Support for typed keys[2].
> * Tests, tests, and more tests.
>
>
> What comes next (after 0.8)
> ---
>
> * Benchmarking and optimization
> * Completion of DDL (ALTER ...).
> * Prepared statements
> * Custom, line protocol (no more Thrift).
> * ... ?
>
>
> What you can do
> ---
>
> * Play/test/experiment, and file bug reports.  The Python driver's
> interactive interpreter is a good place to start (drivers/py/cqlsh).
> * Write system tests (test/system/test_cql.py).
> * Write language drivers.
> * Write documentation.
> * Pick up unclaimed tickets tagged "cql"[3].
> * Port libraries and applications (and file bug reports).
>
> Thoughts, comments, questions?
>
> [1]: https://issues.apache.org/jira/browse/CASSANDRA-1703
> [2]: https://issues.apache.org/jira/browse/CASSANDRA-2311
> [3]: http://goo.gl/cSPlc
>
> --
> Eric Evans
> eev...@rackspace.com
>
>

Re: State Of: CQL

[Gary Dusbabek]

Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
need to do something about this before it gets out of hand.

I've been thinking about alternatives all weekend.  Here's one thing I
came up with that I think will do nicely.

Using our thrift API (the *old* way of doing things) had a tendency to
let low level API paradigms code seep and leak all over application
logic.  But we're not going to have that problem using CQL.  So I
thought "seepless" would be a good name because your data code would
stop seeping.

Then I realized that it didn't boil down to a cool acronym or even
have a symbol in it.  In grand fashion, I added a plus to the end of
seepless to arrive at "seepless+".  I think it has a nice ring and
will fit easily into Cassandra discussions:

"A great way to use Cassandra is write queries using seepless+."
"We've got seepless+ drivers for several languages including java and python."
"We're not using thrift anymore; we write all of our queries in seepless+ now."

Anyway, I'll keep thinking to see if I can come up with something
better.  I'm full of ideas this weekend.

Gary.


On Fri, Mar 18, 2011 at 14:54, Eric Evans  wrote:
>
> With 3 weeks and change until the branch-and-feature-freeze, I thought
> I'd take a few moments to update everyone on the current state of CQL.
>
> Goals and Progress[1]
> -
> The overarching goal of course, is to create a compelling replacement
> for the RPC interface, one that is less baroque, comparable in
> performance, and stable across Cassandra release versions.
>
> The goals for Cassandra 0.8 are to meet or exceed the point of minimum
> usability.  That is to say, a significant number of users/applications
> can make use of it.  I believe we're on track to achieve that.
>
> Already complete:
> * Complete data manipulation (SELECT, UPDATE, DELETE, TRUNCATE ...)
> * Partial DDL, enough to create a schema, (ALTER is missing).
> * Drivers for Python (including Twisted), and Java (JDBC).
> * Language documentation (doc/cql/CQL.html)
>
> Remaining for 0.8:
> * Support for typed keys[2].
> * Tests, tests, and more tests.
>
>
> What comes next (after 0.8)
> ---
>
> * Benchmarking and optimization
> * Completion of DDL (ALTER ...).
> * Prepared statements
> * Custom, line protocol (no more Thrift).
> * ... ?
>
>
> What you can do
> ---
>
> * Play/test/experiment, and file bug reports.  The Python driver's
> interactive interpreter is a good place to start (drivers/py/cqlsh).
> * Write system tests (test/system/test_cql.py).
> * Write language drivers.
> * Write documentation.
> * Pick up unclaimed tickets tagged "cql"[3].
> * Port libraries and applications (and file bug reports).
>
> Thoughts, comments, questions?
>
> [1]: https://issues.apache.org/jira/browse/CASSANDRA-1703
> [2]: https://issues.apache.org/jira/browse/CASSANDRA-2311
> [3]: http://goo.gl/cSPlc
>
> --
> Eric Evans
> eev...@rackspace.com
>

Re: State Of: CQL

[Andy Twigg]

SQL = "structured query language", so (since cassandra is partially about
unstructured data), what about "unstructured query language" = UQL ?


On 20 March 2011 12:29, Gary Dusbabek  wrote:

> Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
> need to do something about this before it gets out of hand.
>
> I've been thinking about alternatives all weekend.  Here's one thing I
> came up with that I think will do nicely.
>
> Using our thrift API (the *old* way of doing things) had a tendency to
> let low level API paradigms code seep and leak all over application
> logic.  But we're not going to have that problem using CQL.  So I
> thought "seepless" would be a good name because your data code would
> stop seeping.
>
> Then I realized that it didn't boil down to a cool acronym or even
> have a symbol in it.  In grand fashion, I added a plus to the end of
> seepless to arrive at "seepless+".  I think it has a nice ring and
> will fit easily into Cassandra discussions:
>
> "A great way to use Cassandra is write queries using seepless+."
> "We've got seepless+ drivers for several languages including java and
> python."
> "We're not using thrift anymore; we write all of our queries in seepless+
> now."
>
> Anyway, I'll keep thinking to see if I can come up with something
> better.  I'm full of ideas this weekend.
>
> Gary.
>
>
> On Fri, Mar 18, 2011 at 14:54, Eric Evans  wrote:
> >
> > With 3 weeks and change until the branch-and-feature-freeze, I thought
> > I'd take a few moments to update everyone on the current state of CQL.
> >
> > Goals and Progress[1]
> > -
> > The overarching goal of course, is to create a compelling replacement
> > for the RPC interface, one that is less baroque, comparable in
> > performance, and stable across Cassandra release versions.
> >
> > The goals for Cassandra 0.8 are to meet or exceed the point of minimum
> > usability.  That is to say, a significant number of users/applications
> > can make use of it.  I believe we're on track to achieve that.
> >
> > Already complete:
> > * Complete data manipulation (SELECT, UPDATE, DELETE, TRUNCATE ...)
> > * Partial DDL, enough to create a schema, (ALTER is missing).
> > * Drivers for Python (including Twisted), and Java (JDBC).
> > * Language documentation (doc/cql/CQL.html)
> >
> > Remaining for 0.8:
> > * Support for typed keys[2].
> > * Tests, tests, and more tests.
> >
> >
> > What comes next (after 0.8)
> > ---
> >
> > * Benchmarking and optimization
> > * Completion of DDL (ALTER ...).
> > * Prepared statements
> > * Custom, line protocol (no more Thrift).
> > * ... ?
> >
> >
> > What you can do
> > ---
> >
> > * Play/test/experiment, and file bug reports.  The Python driver's
> > interactive interpreter is a good place to start (drivers/py/cqlsh).
> > * Write system tests (test/system/test_cql.py).
> > * Write language drivers.
> > * Write documentation.
> > * Pick up unclaimed tickets tagged "cql"[3].
> > * Port libraries and applications (and file bug reports).
> >
> > Thoughts, comments, questions?
> >
> > [1]: https://issues.apache.org/jira/browse/CASSANDRA-1703
> > [2]: https://issues.apache.org/jira/browse/CASSANDRA-2311
> > [3]: http://goo.gl/cSPlc
> >
> > --
> > Eric Evans
> > eev...@rackspace.com
> >
>



-- 
+447799647538
www.acunu.com

Re: State Of: CQL

[Andy Grundman]

Cassandra Interface Language == CassIL == "Castle" ?

On Mar 20, 2011, at 8:35 AM, Andy Twigg wrote:

> SQL = "structured query language", so (since cassandra is partially about
> unstructured data), what about "unstructured query language" = UQL ?
> 
> 
> On 20 March 2011 12:29, Gary Dusbabek  wrote:
> 
>> Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
>> need to do something about this before it gets out of hand.

Re: State Of: CQL

[Daniel Lundin]

Conservatively and true to the initial name:

CassQL => Cassandra Query Language

A bit more left-field:

CQ => Cassandra Query
CL => Cassandra Language

I'm partial to CQ myself, as it:
 * Suggests a verb - "seek".
 * Has geeky secondary [but highly relevant] meaning:
http://en.wikipedia.org/wiki/CQ_(call)
 * Is typographically striking, suggesting infinity.

On Sun, Mar 20, 2011 at 1:44 PM, Andy Grundman  wrote:
> Cassandra Interface Language == CassIL == "Castle" ?
>
> On Mar 20, 2011, at 8:35 AM, Andy Twigg wrote:
>
>> SQL = "structured query language", so (since cassandra is partially about
>> unstructured data), what about "unstructured query language" = UQL ?
>>
>>
>> On 20 March 2011 12:29, Gary Dusbabek  wrote:
>>
>>> Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
>>> need to do something about this before it gets out of hand.
>

Re: State Of: CQL

[Jeremy Hanna]

I like Castle - sounds cool, though it mixes metaphors.  Greek mythology and 
medieval Europe...  Still I think it's a cool name.

On Mar 20, 2011, at 7:44 AM, Andy Grundman wrote:

> Cassandra Interface Language == CassIL == "Castle" ?
> 
> On Mar 20, 2011, at 8:35 AM, Andy Twigg wrote:
> 
>> SQL = "structured query language", so (since cassandra is partially about
>> unstructured data), what about "unstructured query language" = UQL ?
>> 
>> 
>> On 20 March 2011 12:29, Gary Dusbabek  wrote:
>> 
>>> Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
>>> need to do something about this before it gets out of hand.

Re: State Of: CQL

[Joseph Bowman]

How about Prophecy? That was Cassandra's talent. For short it could be CPL
or PL. Cassandra Prophecy Language
On Mar 20, 2011 10:10 AM, "Jeremy Hanna"  wrote:

Re: State Of: CQL

[Jake Luciani]

I for one still like YesQL

On Sun, Mar 20, 2011 at 8:29 AM, Gary Dusbabek  wrote:

> Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
> need to do something about this before it gets out of hand.
>
> I've been thinking about alternatives all weekend.  Here's one thing I
> came up with that I think will do nicely.
>
> Using our thrift API (the *old* way of doing things) had a tendency to
> let low level API paradigms code seep and leak all over application
> logic.  But we're not going to have that problem using CQL.  So I
> thought "seepless" would be a good name because your data code would
> stop seeping.
>
> Then I realized that it didn't boil down to a cool acronym or even
> have a symbol in it.  In grand fashion, I added a plus to the end of
> seepless to arrive at "seepless+".  I think it has a nice ring and
> will fit easily into Cassandra discussions:
>
> "A great way to use Cassandra is write queries using seepless+."
> "We've got seepless+ drivers for several languages including java and
> python."
> "We're not using thrift anymore; we write all of our queries in seepless+
> now."
>
> Anyway, I'll keep thinking to see if I can come up with something
> better.  I'm full of ideas this weekend.
>
> Gary.
>
>
> On Fri, Mar 18, 2011 at 14:54, Eric Evans  wrote:
> >
> > With 3 weeks and change until the branch-and-feature-freeze, I thought
> > I'd take a few moments to update everyone on the current state of CQL.
> >
> > Goals and Progress[1]
> > -
> > The overarching goal of course, is to create a compelling replacement
> > for the RPC interface, one that is less baroque, comparable in
> > performance, and stable across Cassandra release versions.
> >
> > The goals for Cassandra 0.8 are to meet or exceed the point of minimum
> > usability.  That is to say, a significant number of users/applications
> > can make use of it.  I believe we're on track to achieve that.
> >
> > Already complete:
> > * Complete data manipulation (SELECT, UPDATE, DELETE, TRUNCATE ...)
> > * Partial DDL, enough to create a schema, (ALTER is missing).
> > * Drivers for Python (including Twisted), and Java (JDBC).
> > * Language documentation (doc/cql/CQL.html)
> >
> > Remaining for 0.8:
> > * Support for typed keys[2].
> > * Tests, tests, and more tests.
> >
> >
> > What comes next (after 0.8)
> > ---
> >
> > * Benchmarking and optimization
> > * Completion of DDL (ALTER ...).
> > * Prepared statements
> > * Custom, line protocol (no more Thrift).
> > * ... ?
> >
> >
> > What you can do
> > ---
> >
> > * Play/test/experiment, and file bug reports.  The Python driver's
> > interactive interpreter is a good place to start (drivers/py/cqlsh).
> > * Write system tests (test/system/test_cql.py).
> > * Write language drivers.
> > * Write documentation.
> > * Pick up unclaimed tickets tagged "cql"[3].
> > * Port libraries and applications (and file bug reports).
> >
> > Thoughts, comments, questions?
> >
> > [1]: https://issues.apache.org/jira/browse/CASSANDRA-1703
> > [2]: https://issues.apache.org/jira/browse/CASSANDRA-2311
> > [3]: http://goo.gl/cSPlc
> >
> > --
> > Eric Evans
> > eev...@rackspace.com
> >
>



-- 
http://twitter.com/tjake

Re: State Of: CQL

[Tyler Hobbs]

YesQL is the only one that's made me laugh out loud so far.  I'm a fan of
that if we want to keep it light-hearted.

I think CassQL and Castle are both reasonable.  'seepless' has a great idea
behind it, but it sounds a lot like like 'sleepless'.

On Sun, Mar 20, 2011 at 11:06 AM, Jake Luciani  wrote:

> I for one still like YesQL
>
> On Sun, Mar 20, 2011 at 8:29 AM, Gary Dusbabek 
> wrote:
>
> > Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
> > need to do something about this before it gets out of hand.
> >
> > I've been thinking about alternatives all weekend.  Here's one thing I
> > came up with that I think will do nicely.
> >
> > Using our thrift API (the *old* way of doing things) had a tendency to
> > let low level API paradigms code seep and leak all over application
> > logic.  But we're not going to have that problem using CQL.  So I
> > thought "seepless" would be a good name because your data code would
> > stop seeping.
> >
> > Then I realized that it didn't boil down to a cool acronym or even
> > have a symbol in it.  In grand fashion, I added a plus to the end of
> > seepless to arrive at "seepless+".  I think it has a nice ring and
> > will fit easily into Cassandra discussions:
> >
> > "A great way to use Cassandra is write queries using seepless+."
> > "We've got seepless+ drivers for several languages including java and
> > python."
> > "We're not using thrift anymore; we write all of our queries in seepless+
> > now."
> >
> > Anyway, I'll keep thinking to see if I can come up with something
> > better.  I'm full of ideas this weekend.
> >
> > Gary.
> >
> >
> > On Fri, Mar 18, 2011 at 14:54, Eric Evans  wrote:
> > >
> > > With 3 weeks and change until the branch-and-feature-freeze, I thought
> > > I'd take a few moments to update everyone on the current state of CQL.
> > >
> > > Goals and Progress[1]
> > > -
> > > The overarching goal of course, is to create a compelling replacement
> > > for the RPC interface, one that is less baroque, comparable in
> > > performance, and stable across Cassandra release versions.
> > >
> > > The goals for Cassandra 0.8 are to meet or exceed the point of minimum
> > > usability.  That is to say, a significant number of users/applications
> > > can make use of it.  I believe we're on track to achieve that.
> > >
> > > Already complete:
> > > * Complete data manipulation (SELECT, UPDATE, DELETE, TRUNCATE ...)
> > > * Partial DDL, enough to create a schema, (ALTER is missing).
> > > * Drivers for Python (including Twisted), and Java (JDBC).
> > > * Language documentation (doc/cql/CQL.html)
> > >
> > > Remaining for 0.8:
> > > * Support for typed keys[2].
> > > * Tests, tests, and more tests.
> > >
> > >
> > > What comes next (after 0.8)
> > > ---
> > >
> > > * Benchmarking and optimization
> > > * Completion of DDL (ALTER ...).
> > > * Prepared statements
> > > * Custom, line protocol (no more Thrift).
> > > * ... ?
> > >
> > >
> > > What you can do
> > > ---
> > >
> > > * Play/test/experiment, and file bug reports.  The Python driver's
> > > interactive interpreter is a good place to start (drivers/py/cqlsh).
> > > * Write system tests (test/system/test_cql.py).
> > > * Write language drivers.
> > > * Write documentation.
> > > * Pick up unclaimed tickets tagged "cql"[3].
> > > * Port libraries and applications (and file bug reports).
> > >
> > > Thoughts, comments, questions?
> > >
> > > [1]: https://issues.apache.org/jira/browse/CASSANDRA-1703
> > > [2]: https://issues.apache.org/jira/browse/CASSANDRA-2311
> > > [3]: http://goo.gl/cSPlc
> > >
> > > --
> > > Eric Evans
> > > eev...@rackspace.com
> > >
> >
>
>
>
> --
> http://twitter.com/tjake
>



-- 
Tyler Hobbs
Software Engineer, DataStax 
Maintainer of the pycassa  Cassandra
Python client library

Re: State Of: CQL

[Jeremy Hanna]

I wonder if drivers for various languages could be google summer of code 
projects.  On the one hand it's a nice intro to cassandra and a discrete thing 
to do.  However, would that leave it maintainerless once gsoc was done...?

On Mar 20, 2011, at 11:42 AM, Tyler Hobbs wrote:

> YesQL is the only one that's made me laugh out loud so far.  I'm a fan of
> that if we want to keep it light-hearted.
> 
> I think CassQL and Castle are both reasonable.  'seepless' has a great idea
> behind it, but it sounds a lot like like 'sleepless'.
> 
> On Sun, Mar 20, 2011 at 11:06 AM, Jake Luciani  wrote:
> 
>> I for one still like YesQL
>> 
>> On Sun, Mar 20, 2011 at 8:29 AM, Gary Dusbabek 
>> wrote:
>> 
>>> Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
>>> need to do something about this before it gets out of hand.
>>> 
>>> I've been thinking about alternatives all weekend.  Here's one thing I
>>> came up with that I think will do nicely.
>>> 
>>> Using our thrift API (the *old* way of doing things) had a tendency to
>>> let low level API paradigms code seep and leak all over application
>>> logic.  But we're not going to have that problem using CQL.  So I
>>> thought "seepless" would be a good name because your data code would
>>> stop seeping.
>>> 
>>> Then I realized that it didn't boil down to a cool acronym or even
>>> have a symbol in it.  In grand fashion, I added a plus to the end of
>>> seepless to arrive at "seepless+".  I think it has a nice ring and
>>> will fit easily into Cassandra discussions:
>>> 
>>> "A great way to use Cassandra is write queries using seepless+."
>>> "We've got seepless+ drivers for several languages including java and
>>> python."
>>> "We're not using thrift anymore; we write all of our queries in seepless+
>>> now."
>>> 
>>> Anyway, I'll keep thinking to see if I can come up with something
>>> better.  I'm full of ideas this weekend.
>>> 
>>> Gary.
>>> 
>>> 
>>> On Fri, Mar 18, 2011 at 14:54, Eric Evans  wrote:
 
 With 3 weeks and change until the branch-and-feature-freeze, I thought
 I'd take a few moments to update everyone on the current state of CQL.
 
 Goals and Progress[1]
 -
 The overarching goal of course, is to create a compelling replacement
 for the RPC interface, one that is less baroque, comparable in
 performance, and stable across Cassandra release versions.
 
 The goals for Cassandra 0.8 are to meet or exceed the point of minimum
 usability.  That is to say, a significant number of users/applications
 can make use of it.  I believe we're on track to achieve that.
 
 Already complete:
 * Complete data manipulation (SELECT, UPDATE, DELETE, TRUNCATE ...)
 * Partial DDL, enough to create a schema, (ALTER is missing).
 * Drivers for Python (including Twisted), and Java (JDBC).
 * Language documentation (doc/cql/CQL.html)
 
 Remaining for 0.8:
 * Support for typed keys[2].
 * Tests, tests, and more tests.
 
 
 What comes next (after 0.8)
 ---
 
 * Benchmarking and optimization
 * Completion of DDL (ALTER ...).
 * Prepared statements
 * Custom, line protocol (no more Thrift).
 * ... ?
 
 
 What you can do
 ---
 
 * Play/test/experiment, and file bug reports.  The Python driver's
 interactive interpreter is a good place to start (drivers/py/cqlsh).
 * Write system tests (test/system/test_cql.py).
 * Write language drivers.
 * Write documentation.
 * Pick up unclaimed tickets tagged "cql"[3].
 * Port libraries and applications (and file bug reports).
 
 Thoughts, comments, questions?
 
 [1]: https://issues.apache.org/jira/browse/CASSANDRA-1703
 [2]: https://issues.apache.org/jira/browse/CASSANDRA-2311
 [3]: http://goo.gl/cSPlc
 
 --
 Eric Evans
 eev...@rackspace.com
 
>>> 
>> 
>> 
>> 
>> --
>> http://twitter.com/tjake
>> 
> 
> 
> 
> -- 
> Tyler Hobbs
> Software Engineer, DataStax 
> Maintainer of the pycassa  Cassandra
> Python client library

Re: State Of: CQL

[Courtney Robinson]

Possibly, I think doing a gsoc would leave a few dead projects and in the 
end someone would decide to pick up one or two of them and possibly take 
development in a diff. direction than was intended. Much like the multitude 
of clients that start, die and get re-born.


--
From: "Jeremy Hanna" 
Sent: Sunday, March 20, 2011 9:22 PM
To: 
Subject: Re: State Of: CQL

I wonder if drivers for various languages could be google summer of code 
projects.  On the one hand it's a nice intro to cassandra and a discrete 
thing to do.  However, would that leave it maintainerless once gsoc was 
done...?


On Mar 20, 2011, at 11:42 AM, Tyler Hobbs wrote:


YesQL is the only one that's made me laugh out loud so far.  I'm a fan of
that if we want to keep it light-hearted.

I think CassQL and Castle are both reasonable.  'seepless' has a great 
idea

behind it, but it sounds a lot like like 'sleepless'.

On Sun, Mar 20, 2011 at 11:06 AM, Jake Luciani  wrote:


I for one still like YesQL

On Sun, Mar 20, 2011 at 8:29 AM, Gary Dusbabek 
wrote:


Everybody is right.  The CQL<->SQL naming ambiguity is a problem.  We
need to do something about this before it gets out of hand.

I've been thinking about alternatives all weekend.  Here's one thing I
came up with that I think will do nicely.

Using our thrift API (the *old* way of doing things) had a tendency to
let low level API paradigms code seep and leak all over application
logic.  But we're not going to have that problem using CQL.  So I
thought "seepless" would be a good name because your data code would
stop seeping.

Then I realized that it didn't boil down to a cool acronym or even
have a symbol in it.  In grand fashion, I added a plus to the end of
seepless to arrive at "seepless+".  I think it has a nice ring and
will fit easily into Cassandra discussions:

"A great way to use Cassandra is write queries using seepless+."
"We've got seepless+ drivers for several languages including java and
python."
"We're not using thrift anymore; we write all of our queries in 
seepless+

now."

Anyway, I'll keep thinking to see if I can come up with something
better.  I'm full of ideas this weekend.

Gary.


On Fri, Mar 18, 2011 at 14:54, Eric Evans  wrote:


With 3 weeks and change until the branch-and-feature-freeze, I thought
I'd take a few moments to update everyone on the current state of CQL.

Goals and Progress[1]
-
The overarching goal of course, is to create a compelling replacement
for the RPC interface, one that is less baroque, comparable in
performance, and stable across Cassandra release versions.

The goals for Cassandra 0.8 are to meet or exceed the point of minimum
usability.  That is to say, a significant number of users/applications
can make use of it.  I believe we're on track to achieve that.

Already complete:
* Complete data manipulation (SELECT, UPDATE, DELETE, TRUNCATE ...)
* Partial DDL, enough to create a schema, (ALTER is missing).
* Drivers for Python (including Twisted), and Java (JDBC).
* Language documentation (doc/cql/CQL.html)

Remaining for 0.8:
* Support for typed keys[2].
* Tests, tests, and more tests.


What comes next (after 0.8)
---

* Benchmarking and optimization
* Completion of DDL (ALTER ...).
* Prepared statements
* Custom, line protocol (no more Thrift).
* ... ?


What you can do
---

* Play/test/experiment, and file bug reports.  The Python driver's
interactive interpreter is a good place to start (drivers/py/cqlsh).
* Write system tests (test/system/test_cql.py).
* Write language drivers.
* Write documentation.
* Pick up unclaimed tickets tagged "cql"[3].
* Port libraries and applications (and file bug reports).

Thoughts, comments, questions?

[1]: https://issues.apache.org/jira/browse/CASSANDRA-1703
[2]: https://issues.apache.org/jira/browse/CASSANDRA-2311
[3]: http://goo.gl/cSPlc

--
Eric Evans
eev...@rackspace.com







--
http://twitter.com/tjake





--
Tyler Hobbs
Software Engineer, DataStax 
Maintainer of the pycassa  Cassandra
Python client library

Re: State Of: CQL - driver devs

[Courtney Robinson]

I've been looking at the Java and Python drivers and they are both using 
Thrift. I thought the idea was to get rid of thrift/avro?


The two implemented (however partial) drivers seem to have similar naming 
conventions for class and methods.
Has it been agreed to try and do this? I reckon it'd be a good idea if that 
was the case because then no matter which language driver you're using you
you can easily use any other driver/language since the methods/function 
names would be the same or similar and would mean its easier to
develop different components in different languages since you won't have to 
learn a new API for the various drivers... or at least you'd have an easier 
time


I think this would address one of the problems now with different clients 
providing their own API which vary widely across the board.


Maybe using UML to indicate which methods/functions each driver needs to 
provide. I generated some UML from the Java driver and from that result
the only issue I can think of in languages like PHP that don't have a 
Collections API data return types would have to be appropriate to the 
language.


Thoughts? 

Re: State Of: CQL - driver devs

[Eric Evans]

On Sun, 2011-03-20 at 22:11 +, Courtney Robinson wrote:
> I've been looking at the Java and Python drivers and they are both
> using Thrift. I thought the idea was to get rid of thrift/avro?

The idea is to create an alternative to the tightly-coupled
object-oriented RPC interface.

This initial version uses Thrift so that effort could be focused on
implementing the language, and have something useful for this release.
And, until it's complete (see my original mail for the list of
outstanding items), the RPC methods can serve to fill in the holes.
Baby steps.

(Hopefully )for the next version, we'll replace Thrift with a dedicated
protocol, one that eliminates the Thrift dependency, and more
importantly, implements streaming.  This should be transparent to
applications for the most part though.

> The two implemented (however partial) drivers seem to have similar
> naming conventions for class and methods.  Has it been agreed to try
> and do this?

Yes, insomuch as this is reasonable/practical.

> I reckon it'd be a good idea if that was the case because then no
> matter which language driver you're using you you can easily use any
> other driver/language since the methods/function names would be the
> same or similar and would mean its easier to develop different
> components in different languages since you won't have to learn a new
> API for the various drivers... or at least you'd have an easier time
> 
> I think this would address one of the problems now with different
> clients providing their own API which vary widely across the board.

For the record, I don't see CQL (and its drivers) as a replacement for
high-level idiomatic client libraries.  In much the same way as projects
like Spring, and Hiberate, or SQLAlchemy provide abstraction for RBDMS
and SQL, we'll still have client libraries which build their own APIs,
according to their own requirements, on top of CQL.

-- 
Eric Evans
eev...@rackspace.com