Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 02D9CC132 for ; Thu, 3 May 2012 18:53:12 +0000 (UTC) Received: (qmail 16651 invoked by uid 500); 3 May 2012 18:53:09 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 16611 invoked by uid 500); 3 May 2012 18:53:09 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 16602 invoked by uid 99); 3 May 2012 18:53:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 May 2012 18:53:09 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of eczech52@gmail.com designates 209.85.217.172 as permitted sender) Received: from [209.85.217.172] (HELO mail-lb0-f172.google.com) (209.85.217.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 May 2012 18:53:05 +0000 Received: by lbbgo11 with SMTP id go11so1712238lbb.31 for ; Thu, 03 May 2012 11:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=kIW8+fj4YE8bej3SjCjeGurU4LBmnUYP+UQzbvy48Ts=; b=ODxOYFiQp7xYV8MmAPg4PgEk+1ODIkiXz3+nvN1aqLjjlR6meC8W/tjmiYST3oM3vn 5iaRvt51452i+PtuRFJuVT7fASHXQjeHMSE2urVCHGhpO2N1MmUHE16jSgun28lhClfE ljqJVDDmnYUEZe6Gtyu2FCQyqBiBpxTO0A0m+wgKENBD4zt+0OAG9sEa3cspMIKYkane DTxKtMvCz8dlvlQMtRNnRpxBWOqvo9Ck4Ak3xelOw0H2bGaQMM0dd+pi5IdJ1+430QA2 qdmcF3oTg3jQYRVr5YzOELUYvJDIZQL56DfJFouObIpCAAzFnA19xPSmQPM5Bb0J3KEO aYOg== Received: by 10.112.85.39 with SMTP id e7mr1511948lbz.56.1336071163655; Thu, 03 May 2012 11:52:43 -0700 (PDT) MIME-Version: 1.0 Sender: eczech52@gmail.com Received: by 10.152.114.99 with HTTP; Thu, 3 May 2012 11:52:23 -0700 (PDT) In-Reply-To: References: From: Eric Czech Date: Thu, 3 May 2012 14:52:23 -0400 X-Google-Sender-Auth: fiTOTz16KPielpKKEvzH9pGLZV4 Message-ID: Subject: Re: odd CQL behavior To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec555547e1ab70204bf264f3f X-Virus-Checked: Checked by ClamAV on apache.org --bcaec555547e1ab70204bf264f3f Content-Type: text/plain; charset=ISO-8859-1 Alright, thanks again! I guess I'll stick to the CLI since I'd rather not make schema changes for the sake of querying (we have hundreds of column families and I don't want to make that change everywhere). On Thu, May 3, 2012 at 2:41 PM, paul cannon wrote: > Very sadly, no. It's not (yet?) meant to be a particularly good > interactive language, so the only "function" in cql is COUNT(), and that's > really just special syntax. It seems, though, that you might actually be > better off with a key of type 'ascii' or 'text', if that's how you expect > to work with it. Would it be an option to adjust that table? > > The ASSUME-changes-outgoing-cql ticket (CASSANDRA-3799) would also help, > so maybe keep an eye on that. > > p > > > On Thu, May 3, 2012 at 1:22 PM, Eric Czech wrote: > >> Gotcha, I probably should have guessed that much. Does CQL have any >> functions to convert ascii to hex so that I don't have to do that >> conversion elsewhere (I don't see one in the docs)? >> >> >> On Thu, May 3, 2012 at 2:09 PM, paul cannon wrote: >> >>> On Thu, May 3, 2012 at 12:46 PM, Eric Czech wrote: >>> >>>> I can't believe I have to ask this but I have a CF with about 10 rows >>>> and the keys are literally 1 through 9. >>>> >>>> Why does this not work if I want the row where the key is ascii('5')? >>>> >>>> cqlsh:Keyspace1> select first 1 * from CF where key = '5'; >>>> KEY >>>> ----- >>>> 05 >>>> >>> >>> This depends on the configured type (key_validation) of the key. From >>> what you've posted, it looks like CQL is treating it as 'blob', not 'ascii'. >>> >>> * I saw the Jira about the sort of phantom row with no values so I know >>>> why that's there >>>> >>>> Listing the keys shows something like this: >>>> >>>> cqlsh:Keyspace1> select key from CF ; >>>> key >>>> ------ >>>> 33 >>>> 36 >>>> 35 >>>> 38 >>>> 32 >>>> 31 >>>> 39 >>>> 34 >>>> 37 >>>> >>>> If I prepend a '3' to my key queries it works but I can't possibly see >>>> why I would have to do that. >>>> >>>> cqlsh:Keyspace1> select first 1 * from CF where key = '35'; >>>> ( Returns the right rows for key '5') >>>> >>> >>> Cause 35 is hex for ascii(5), as you pointed out. >>> >>> Changing the validator appears to make no material difference beyond the >>>> key listing: >>>> >>> >>> This is because ASSUME is only a cqlsh feature, and only affects how >>> data is deserialized. There is a ticket out for cqlsh also to mangle your >>> outgoing CQL statements to match ASSUMEd types too, but that's not there >>> yet. >>> >>> HTH, >>> p >>> >> >> > --bcaec555547e1ab70204bf264f3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alright, thanks again!
=A0
I guess I'll stick to the CLI = since I'd rather not make schema changes for the sake of querying (we h= ave hundreds of column families and I don't want to make that change ev= erywhere).

On Thu, May 3, 2012 at 2:41 PM, paul cannon = <paul@datastax.com> wrote:
Very sadly, no. =A0It's not (yet?) meant to be a particularly good inte= ractive language, so the only "function" in cql is COUNT(), and t= hat's really just special syntax. It seems, though, that you might actu= ally be better off with a key of type 'ascii' or 'text', if= that's how you expect to work with it. =A0Would it be an option to adj= ust that table?

The ASSUME-changes-outgoing-cql ticket (CASSANDRA-3799) woul= d also help, so maybe keep an eye on that.

p


On Thu, May 3, 2012 at= 1:22 PM, Eric Czech <eric@nextbigsound.com> wrote:
Gotcha, I probably should have guessed that = much. =A0Does CQL have any functions to convert ascii to hex so that I don&= #39;t have to do that conversion elsewhere (I don't see one in the docs= )?


On Thu, May 3, 2012 at 2:09 PM, paul cannon <paul@datastax.com> wrote:
On Thu, May 3, 2012 at 12:46 PM, Eric Czech <eric@nextbigsound.co= m> wrote:
I can't believe I have to ask this but I have a CF with about 10 rows a= nd the keys are literally 1 through 9. =A0

Why does this= not work if I want the row where the key is ascii('5')?

cqlsh:Keyspace1> =A0select first 1 * from CF where key =3D '5&#= 39;;
=A0KEY
-----
=A0 05

This depends on the configured typ= e (key_validation) of the key. From what you've posted, it looks like C= QL is treating it as 'blob', not 'ascii'.

* I saw the Jira ab= out the sort of phantom row with no values so I know why that's there

Listing the keys shows something like this:
<= br>
cqlsh:Keyspace1> select key from CF ;
=A0ke= y
------
=A0 =A033
=A0 =A036
=A0 = =A035
=A0 =A038
=A0 =A032
=A0 =A031
=A0 =A039
=
=A0 =A034
=A0 =A037

If I prep= end a '3' to my key queries it works but I can't possibly see w= hy I would have to do that. =A0

cqlsh:Keyspace1> =A0 select first 1 * from CF =A0whe= re key =3D '35';
( Returns the right rows for key '5&= #39;)

Cause 35 is hex for= ascii(5), as you pointed out.

Changing the valida= tor appears to make no material difference beyond the key listing:

This is because ASSUME is only a cql= sh feature, and only affects how data is deserialized. =A0There is a ticket= out for cqlsh also to mangle your outgoing CQL statements to match ASSUMEd= types too, but that's not there yet.

HTH,
p



--bcaec555547e1ab70204bf264f3f--