On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg c...@pobox.com wrote:
CS Short answer: YES Please, but we will still want a side channel for
CS minimum overhead.
100% agreed on both counts. But IIRC the fastest side channel is to
become a Cassandra node. Is that an option?
CS Long answer:
2010/10/29 Ted Zlatanov t...@lifelogs.com:
On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg c...@pobox.com wrote:
CS Short answer: YES Please, but we will still want a side channel for
CS minimum overhead.
100% agreed on both counts. But IIRC the fastest side channel is to
become a
On Fri, 29 Oct 2010 09:29:43 -0500 Gary Dusbabek gdusba...@gmail.com wrote:
GD 2010/10/29 Ted Zlatanov t...@lifelogs.com:
On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg c...@pobox.com wrote:
CS Short answer: YES Please, but we will still want a side channel for
CS minimum overhead.
To: dev@cassandra.apache.org
Subject: Re: NoSQL, YesCQL?
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
On 10/29/2010 7:13 AM, Ted Zlatanov wrote:
On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg c...@pobox.com wrote:
CS Short answer: YES Please, but we will still want a side channel for
CS minimum overhead.
100% agreed on both counts. But IIRC the fastest side channel is to
become a
2010/10/29 Ted Zlatanov t...@lifelogs.com:
I think the sane, reasonable, simple path is to make the query language
as similar to SQL as possible (which EricQL seems to aim for). Just
making the queries pure text would be terrific, in any case. Then a
JDBC driver or a Perl DBD driver (and
On Thu, 2010-10-28 at 15:40 -0500, 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
On Fri, 29 Oct 2010 10:07:43 -0500 (CDT) Stu Hood stu.h...@rackspace.com
wrote:
SH Most reasonable languages these days have a way to define what looks
SH like a DSL: giving people a text DSL which is subject to injection
SH attacks and can't be type checked without support from a client
SH
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
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
little
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 tests so
On Thu, Oct 28, 2010 at 1:40 PM, Eric Evans eev...@rackspace.com 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
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
13 matches
Mail list logo
