On Fri, 29 Oct 2010 10:07:43 -0500 (CDT) "Stu Hood"
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> driver anyway is bra
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 maintainer
2010/10/29 Ted Zlatanov :
> 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 their parallels i
On 10/29/2010 7:13 AM, Ted Zlatanov wrote:
> On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg 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 Cassandr
The stress.py command:
1. python contrib/py_stress/stress.py -C 32 -x keys_bitmap
2. more info from stack trace:
10/10/29 18:15:28 INFO db.Memtable: Writing
memtable-standa...@23048841(17806140
bytes, 349140 operations)
10/10/29 18:15:29 INFO service.GCInspector: GC for PS MarkSweep: 789 ms,
717
Hi,
1. I've tried to apply the patches for this bug. They worked except for the
unit test modifications that git refused to apply.
2. After applying the patches I've run the stress.py script (with 500,000
keys). The script output seems to be fine, but the cassandra console
contains the below exce
Let me preface this by saying: the fact that it looks like SQL doesn't bother
me. But: I think this would be a terrible thing to _focus_ on. Something for
contrib? Sure.
Most reasonable languages these days have a way to define what looks like a
DSL: giving people a text DSL which is subject to
On Fri, 29 Oct 2010 09:29:43 -0500 Gary Dusbabek wrote:
GD> 2010/10/29 Ted Zlatanov :
>> On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg 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
2010/10/29 Ted Zlatanov :
> On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg 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 a
On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg 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: Query lan
How about something simpler/more approachable such as a query api that hides
away the drudgery of thrift/avro rpc api?
On Fri, Oct 29, 2010 at 12:56 AM, Vincent Maher wrote:
> Hi all
>
> I think this is a great idea. If you take out Thrift, which is where
> the bulk of the n00b installation pain
11 matches
Mail list logo
