[VOTE] Release Apache Cassandra 1.0.7 (Strike 2)

2012-01-13 Thread Sylvain Lebresne 
With the fix for CASSANDRA-3733 and CASSANDRA-3625 added on top of the
artifacts of Strike 1, I propose the following artifacts for release as 1.0.7

Sha1: 6a1ed6205cad8d019eb6eda326d7796a8a0dd67b
Git: 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.7-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-062/org/apache/cassandra/apache-cassandra/1.0.7/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-062/

The artifacts as well as the debian package are also available here:
http://people.apache.org/~slebresne/

The vote will be open for 72 hours (longer if needed).

[1]: http://goo.gl/UTfwn (CHANGES.txt)
[2]: http://goo.gl/EHlRp (NEWS.txt)

Re: Prepared Statement support (CASSANDRA-2475)

2012-01-13 Thread Gary Dusbabek 
I'd like to see the clients stay as simple as possible, keeping the
bind parameters as strings.

Not all languages Javascript make it easy to do binary.

Gary.


On Wed, Jan 11, 2012 at 15:14, Eric Evans  wrote:
> On Wed, Dec 14, 2011 at 5:49 PM, Eric Evans  wrote:
>> Thanks to the hard work of Rick Shaw, prepared statements
>> (https://issues.apache.org/jira/browse/CASSANDRA-2475) has been
>> committed to trunk.  However, before you use it, be advised that the
>> API might be changing in the next few days.
>>
>> If it does change, it should be limited to moving the bind parameters
>> from string to bytes, (pending a comparison of the performance).  I'll
>> send another email with the changes, if any, after the API is expected
>> to be stable.
>
> To follow up on this, and to draw the attention of the folks on
> client-dev@ who have some stake in this:
>
> There was some discussion in #2475, and later in #3634, about whether
> clients would supply string, or binary bind arguments for a prepared
> statement.
>
> I encourage anyone that is interesting to read through the tickets,
> but the short version is that since Cassandra uses binary values
> internally, having the clients serialize types to binary would be more
> performant than having Cassandra do it, while string arguments result
> in simpler, easier to code drivers.  Since it boils down to a question
> of trading one thing for another, we agreed to do some performance
> testing so that we could at least put some real numbers to it.
>
> That performance testing is complete.  Again, I encourage you to check
> out the results[2] yourself, but they could be summarized by saying
> that most operations (reads, counter increments, inserts with an
> indexed columns) are equivalent.  It mostly boils down to standard
> inserts which are 10% faster when using binary arguments than for
> string arguments.  It's worth noting (because either way it's awesome
> :)), that even with string arguments, writes using prepared statements
> are 5% faster than RPC (16% with binary arguments).
>
> We need to drive a stake in the ground Real Soon Now, but since this
> issue directly affects client maintainers, I'd be interested in
> hearing what they had to say about this (either here, or in the
> ticket).
>
> Cheers,
>
>
> [1]: https://issues.apache.org/jira/browse/CASSANDRA-2475
> [2]: https://issues.apache.org/jira/browse/CASSANDRA-3634
>
>
> --
> Eric Evans
> Acunu | http://www.acunu.com | @acunu

Re: Prepared Statement support (CASSANDRA-2475)

2012-01-13 Thread Tyler Hobbs 
On Fri, Jan 13, 2012 at 8:11 AM, Gary Dusbabek  wrote:

>
> Not all languages Javascript make it easy to do binary.


PHP also goes in this boat, which leads me to agree with Gary.

-- 
Tyler Hobbs
DataStax

Re: Prepared Statement support (CASSANDRA-2475)

2012-01-13 Thread Jonathan Ellis 
On Fri, Jan 13, 2012 at 9:45 AM, Tyler Hobbs  wrote:
> On Fri, Jan 13, 2012 at 8:11 AM, Gary Dusbabek  wrote:
>
>>
>> Not all languages Javascript make it easy to do binary.
>
>
> PHP also goes in this boat, which leads me to agree with Gary.

I don't get it.  Don't you already have the binary encoding done for
the PHPCassa?

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: Prepared Statement support (CASSANDRA-2475)

2012-01-13 Thread Sylvain Lebresne 
I think CQL has a problem, it doesn't deal with binary correctly.
I have very successfully used C* to store big amounts of small
pictures and CQL just cannot handle that efficiently.

I've looked quickly but I didn't see anywhere in the tests on
CASSANDRA-3634 biggish column values tested (say in the order of 2-3
digits of KB). I'm willing to bet that with that, the difference is
not 10%, because there is the time to serialize/deserialize to string,
but also the exploded size of binary represented as hex strings.

I think prepared statement are a very good candidate to solve that
'handling binary correctly' problem, but only if we use binary for it.
To me that is *very* big argument against Strings. Sure we could add
yet another feature (or some hack) to handle binary, but why bother
when prepared statement with binary gives us that *and* we get 10%
faster writes even for small values.

--
Sylvain


On Fri, Jan 13, 2012 at 5:01 PM, Jonathan Ellis  wrote:
> On Fri, Jan 13, 2012 at 9:45 AM, Tyler Hobbs  wrote:
>> On Fri, Jan 13, 2012 at 8:11 AM, Gary Dusbabek  wrote:
>>
>>>
>>> Not all languages Javascript make it easy to do binary.
>>
>>
>> PHP also goes in this boat, which leads me to agree with Gary.
>
> I don't get it.  Don't you already have the binary encoding done for
> the PHPCassa?
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com

Re: Prepared Statement support (CASSANDRA-2475)

2012-01-13 Thread Jake Luciani 
Not to mention in the case of CFS we deal only in binary blobs.

I'd rather see us add a hex hack for JS and PHP rather then cater to them.

-Jake

On Fri, Jan 13, 2012 at 11:42 AM, Sylvain Lebresne wrote:

> I think CQL has a problem, it doesn't deal with binary correctly.
> I have very successfully used C* to store big amounts of small
> pictures and CQL just cannot handle that efficiently.
>
> I've looked quickly but I didn't see anywhere in the tests on
> CASSANDRA-3634 biggish column values tested (say in the order of 2-3
> digits of KB). I'm willing to bet that with that, the difference is
> not 10%, because there is the time to serialize/deserialize to string,
> but also the exploded size of binary represented as hex strings.
>
> I think prepared statement are a very good candidate to solve that
> 'handling binary correctly' problem, but only if we use binary for it.
> To me that is *very* big argument against Strings. Sure we could add
> yet another feature (or some hack) to handle binary, but why bother
> when prepared statement with binary gives us that *and* we get 10%
> faster writes even for small values.
>
> --
> Sylvain
>
>
> On Fri, Jan 13, 2012 at 5:01 PM, Jonathan Ellis  wrote:
> > On Fri, Jan 13, 2012 at 9:45 AM, Tyler Hobbs  wrote:
> >> On Fri, Jan 13, 2012 at 8:11 AM, Gary Dusbabek 
> wrote:
> >>
> >>>
> >>> Not all languages Javascript make it easy to do binary.
> >>
> >>
> >> PHP also goes in this boat, which leads me to agree with Gary.
> >
> > I don't get it.  Don't you already have the binary encoding done for
> > the PHPCassa?
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder of DataStax, the source for professional Cassandra support
> > http://www.datastax.com
>



-- 
http://twitter.com/tjake

Re: Prepared Statement support (CASSANDRA-2475)

2012-01-13 Thread Jonathan Ellis 
You can always use hex in classic string-based, non-prepared-statements CQL.

On Fri, Jan 13, 2012 at 10:53 AM, Jake Luciani  wrote:
> Not to mention in the case of CFS we deal only in binary blobs.
>
> I'd rather see us add a hex hack for JS and PHP rather then cater to them.
>
> -Jake
>
> On Fri, Jan 13, 2012 at 11:42 AM, Sylvain Lebresne 
> wrote:
>
>> I think CQL has a problem, it doesn't deal with binary correctly.
>> I have very successfully used C* to store big amounts of small
>> pictures and CQL just cannot handle that efficiently.
>>
>> I've looked quickly but I didn't see anywhere in the tests on
>> CASSANDRA-3634 biggish column values tested (say in the order of 2-3
>> digits of KB). I'm willing to bet that with that, the difference is
>> not 10%, because there is the time to serialize/deserialize to string,
>> but also the exploded size of binary represented as hex strings.
>>
>> I think prepared statement are a very good candidate to solve that
>> 'handling binary correctly' problem, but only if we use binary for it.
>> To me that is *very* big argument against Strings. Sure we could add
>> yet another feature (or some hack) to handle binary, but why bother
>> when prepared statement with binary gives us that *and* we get 10%
>> faster writes even for small values.
>>
>> --
>> Sylvain
>>
>>
>> On Fri, Jan 13, 2012 at 5:01 PM, Jonathan Ellis  wrote:
>> > On Fri, Jan 13, 2012 at 9:45 AM, Tyler Hobbs  wrote:
>> >> On Fri, Jan 13, 2012 at 8:11 AM, Gary Dusbabek 
>> wrote:
>> >>
>> >>>
>> >>> Not all languages Javascript make it easy to do binary.
>> >>
>> >>
>> >> PHP also goes in this boat, which leads me to agree with Gary.
>> >
>> > I don't get it.  Don't you already have the binary encoding done for
>> > the PHPCassa?
>> >
>> > --
>> > Jonathan Ellis
>> > Project Chair, Apache Cassandra
>> > co-founder of DataStax, the source for professional Cassandra support
>> > http://www.datastax.com
>>
>
>
>
> --
> http://twitter.com/tjake



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: Prepared Statement support (CASSANDRA-2475)

2012-01-13 Thread Jonathan Ellis 
To throw out a real-world example: I'm working on CASSANDRA-2878
("Allow CQL-based map/reduce") and it simplifies things to have the
"output" from a query (CqlRow/Column, which are binary) the same as
the input parameters [for the resultset KEY > X paging].  Otherwise I
have to convert it to string for the PS, so that the server can
convert it back to binary.

On Wed, Dec 14, 2011 at 5:49 PM, Eric Evans  wrote:
> Hi all,
>
> Thanks to the hard work of Rick Shaw, prepared statements
> (https://issues.apache.org/jira/browse/CASSANDRA-2475) has been
> committed to trunk.  However, before you use it, be advised that the
> API might be changing in the next few days.
>
> If it does change, it should be limited to moving the bind parameters
> from string to bytes, (pending a comparison of the performance).  I'll
> send another email with the changes, if any, after the API is expected
> to be stable.
>
> Thanks,
>
> --
> Eric Evans
> Acunu | http://www.acunu.com | @acunu



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: [VOTE] Release Apache Cassandra 1.0.7 (Strike 2)

2012-01-13 Thread Jonathan Ellis 
+1

On Fri, Jan 13, 2012 at 3:44 AM, Sylvain Lebresne  wrote:
> With the fix for CASSANDRA-3733 and CASSANDRA-3625 added on top of the
> artifacts of Strike 1, I propose the following artifacts for release as 1.0.7
>
> Sha1: 6a1ed6205cad8d019eb6eda326d7796a8a0dd67b
> Git: 
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.7-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-062/org/apache/cassandra/apache-cassandra/1.0.7/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-062/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~slebresne/
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/UTfwn (CHANGES.txt)
> [2]: http://goo.gl/EHlRp (NEWS.txt)



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com