+1
On Tue, Jan 10, 2012 at 11:30 PM, Jonathan Ellis wrote:
> On Tue, Jan 10, 2012 at 3:59 PM, Brandon Williams wrote:
>> On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
>>> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
>>> with CQL;
>>
>> Actually 1391 doesn't, but i
Greetings,
I wanted to mention this to folks who may be running into this
issue. A user on IRC reporting that cloning the cassandra repo on the
apache servers
http://git-wip-us.apache.org/repos/asf/cassandra.git
fails with error
error: RPC failed; result=22, HTTP code = 417
Obviously mo
On Tue, Jan 10, 2012 at 3:59 PM, Brandon Williams wrote:
> On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
>> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
>> with CQL;
>
> Actually 1391 doesn't, but is quite important nonetheless.
The connection there is that if it w
On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
> with CQL;
Actually 1391 doesn't, but is quite important nonetheless.
> All of these (with the exception of 3707, which is relatively quick)
> are in progress, and some (2
On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
> with CQL; I strongly believe that 1.1 needs to be where CQL goes from
> being "the future" to being "the present." We've been promising this
> for almost a year now and it
On Tue, Jan 10, 2012 at 3:03 PM, Jonathan Ellis wrote:
> Those were grandfathered in back in the day by CFMetaData.getKeyName
> simply returning KEY in that case.
>
> So if you have no key_alias defined, or it was defined to KEY, nothing
> changes. But if you did define PK to be something else, t
Those were grandfathered in back in the day by CFMetaData.getKeyName
simply returning KEY in that case.
So if you have no key_alias defined, or it was defined to KEY, nothing
changes. But if you did define PK to be something else, then you need
to use that PK name in your queries. (Which, again,
I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
with CQL; I strongly believe that 1.1 needs to be where CQL goes from
being "the future" to being "the present." We've been promising this
for almost a year now and it's time to deliver.
All of these (with the exception of 3707, w
On Tue, Jan 10, 2012 at 2:45 PM, Jonathan Ellis wrote:
> Pedantic answer: yes, hence the NEWS entry
>
> More accurate answer: we've fixed a bug that allowed nonsense queries
>
> Long answer: we started off requiring the C* row key, aka PRIMARY KEY
> in CQL DDL, to be named "key." We fixed that in
Pedantic answer: yes, hence the NEWS entry
More accurate answer: we've fixed a bug that allowed nonsense queries
Long answer: we started off requiring the C* row key, aka PRIMARY KEY
in CQL DDL, to be named "key." We fixed that in 0.8.1, and required
that SELECT statements use the actual PK name
This is a breaking change, isn't it? Are we breaking the language and
updating the CQL major *again*?
-- Forwarded message --
From:
Date: Tue, Jan 10, 2012 at 2:01 PM
Subject: [1/4] git commit: note that using KEY instead of the defined
key_alias has been removed
To: comm...@ca
Hi,
I think it's what you need :
http://rantav.github.com/hector/build/html/content/services.html
Jérémy
2012/1/10 Michael Vaknine
> Thank you for your reply
> Do you know if there are documentation of hector I can read to understand
> this behavior?
>
> Thanks
> Michael
>
>
> -Original
Thank you for your reply
Do you know if there are documentation of hector I can read to understand this
behavior?
Thanks
Michael
-Original Message-
From: sc...@scode.org [mailto:sc...@scode.org] On Behalf Of Peter Schuller
Sent: Monday, January 09, 2012 5:29 PM
To: dev@cassandra.apache.
13 matches
Mail list logo
