Re: NoSQL, YesCQL?

2010-10-28 Thread Vincent Maher
Hi all I think this is a great idea. If you take out Thrift, which is where the bulk of the n00b installation pain lies, and add a query language and a PHP extension then I think Cassandra will go mainstream. I still need to write a proper blog post for the team but just so you all know, we're h

Re: NoSQL, YesCQL?

2010-10-28 Thread Eric Evans
On Thu, 2010-10-28 at 18:47 -0700, J. Andrew Rogers wrote: > > http://github.com/eevans/cassandra/tree/CQL > > > > You need to be sure you're checking out the "CQL" branch. > > Meta-comment: You probably should not call it CQL. That name is > already used in multiple standards for similar purposes

Re: NoSQL, YesCQL?

2010-10-28 Thread Krishna Sankar
What about BDQL (Big data QL) or just NOQL? Cheers On 10/28/10 Thu Oct 28, 10, "J. Andrew Rogers" wrote: > On Thu, Oct 28, 2010 at 1:40 PM, Eric Evans wrote: >> >> One solution to this is to implement a server-side query language, with >> simple language drivers that manage all of the commo

Re: NoSQL, YesCQL?

2010-10-28 Thread J. Andrew Rogers
On Thu, Oct 28, 2010 at 1:40 PM, Eric Evans wrote: > > One solution to this is to implement a server-side query language, with > simple language drivers that manage all of the common functionality in a > consistent way (statement preparation, connection pooling, etc). > Library maintainers would t

Re: NoSQL, YesCQL?

2010-10-28 Thread Chip Salzenberg
On 10/28/2010 2:56 PM, Eric Evans wrote: > On Thu, 2010-10-28 at 14:46 -0700, Chip Salzenberg wrote: >> Short answer: "YES Please, but we will still want a side channel for >> minimum overhead." > Ok. Though I'm not sure I agree with the "minimum overhead" argument. > > I've only done preliminary

Re: NoSQL, YesCQL?

2010-10-28 Thread Eric Evans
On Thu, 2010-10-28 at 14:46 -0700, Chip Salzenberg wrote: > Short answer: "YES Please, but we will still want a side channel for > minimum overhead." Ok. Though I'm not sure I agree with the "minimum overhead" argument. I've only done preliminary tests so far, but this seems on par (if not a lit

Re: NoSQL, YesCQL?

2010-10-28 Thread Chip Salzenberg
Short answer: "YES Please, but we will still want a side channel for minimum overhead." Long answer: Query languages only work reliably when you have data binding assistance (insert "Bobby Tables" xkcd here). However, they do have the wonderful property of evolving aggressively without requiring

[VOTE] 0.7.0 beta3

2010-10-28 Thread Eric Evans
The RC1 vote[1] was vetoed due to, (among other things), the desire to see more testing after the somewhat disruptive changes made in CASSANDRA-1367[2]. Thus, I propose the follow artifacts for release as beta3. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1028349 0.7.

Re: [VOTE] 0.7.0 RC1 (attempt #2)

2010-10-28 Thread Brandon Williams
On Thu, Oct 28, 2010 at 9:44 AM, Gary Dusbabek wrote: > +1 beta3. > +1 beta3. > -1 on committing huge changes at the end of a cycle of betas. Let's > not do that any more. +1 on Gary's -1 to committing huge changes at the end of a cycle. -Brandon

Re: [VOTE] 0.7.0 RC1 (attempt #2)

2010-10-28 Thread Jonathan Ellis
On Thu, Oct 28, 2010 at 9:44 AM, Gary Dusbabek wrote: > -1 on committing huge changes at the end of a cycle of betas. Let's > not do that any more. Agreed. Glass half full: we won't have to merge between byte[] and ByteBuffer from 0.7 to 0.8. -- Jonathan Ellis Project Chair, Apache Cassandra c

Re: [VOTE] 0.7.0 RC1 (attempt #2)

2010-10-28 Thread Gary Dusbabek
+1 beta3. -1 on committing huge changes at the end of a cycle of betas. Let's not do that any more. Gary. On Thu, Oct 28, 2010 at 05:48, Jonathan Ellis wrote: > I vote for releasing the artifact as-is but as beta3.  Broken HH is > not something we should have in the final release but we need to

Re: [VOTE] 0.7.0 RC1 (attempt #2)

2010-10-28 Thread Sylvain Lebresne
I agree with that. The changes of #1367 are extensive enough that having a beta3 makes sense. On Thu, Oct 28, 2010 at 12:52 PM, Jonathan Ellis wrote: > ... actually this would require rebuilding the artifacts to change the > version string anyway, so I vote for releasing current 0.7 branch as > b

Re: [VOTE] 0.7.0 RC1 (attempt #2)

2010-10-28 Thread Jonathan Ellis
... actually this would require rebuilding the artifacts to change the version string anyway, so I vote for releasing current 0.7 branch as beta3. On Thu, Oct 28, 2010 at 5:47 AM, Jonathan Ellis wrote: > I vote for releasing the artifact as-is but as beta3. Broken HH is not > something we should

Re: [VOTE] 0.7.0 RC1 (attempt #2)

2010-10-28 Thread Jonathan Ellis
I vote for releasing the artifact as-is but as beta3. Broken HH is not something we should have in the final release but we need to get wider testing of the other changes. On Thu, Oct 28, 2010 at 4:26 AM, Sylvain Lebresne wrote: > I think Hinted handoff are buggy in current rc1-snapshot > (see h

Re: [VOTE] 0.7.0 RC1 (attempt #2)

2010-10-28 Thread Sylvain Lebresne
I think Hinted handoff are buggy in current rc1-snapshot (see https://issues.apache.org/jira/browse/CASSANDRA-1672). I think this pretty much prevent hints from being delivered. Don't know if that is considered harmful enough to re-roll RC1. -- Sylvain On Tue, Oct 26, 2010 at 6:09 PM, Eric Evans