Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 48636 invoked from network); 26 Sep 2010 03:21:39 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 26 Sep 2010 03:21:39 -0000 Received: (qmail 82042 invoked by uid 500); 26 Sep 2010 03:21:37 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 81942 invoked by uid 500); 26 Sep 2010 03:21:34 -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 81934 invoked by uid 99); 26 Sep 2010 03:21:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 26 Sep 2010 03:21:32 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a44.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 26 Sep 2010 03:21:25 +0000 Received: from homiemail-a44.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a44.g.dreamhost.com (Postfix) with ESMTP id 60257118064 for ; Sat, 25 Sep 2010 20:21:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=message-id :from:to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references; q=dns; s= thelastpickle.com; b=JMLQ/AXgRTxilBxyCsX47exXyLZqmltgsC4ByQwHEvM ldWzWYcu01Yr6U2FnXVy/TAKdvgQ4QhCLtVJZapHsvTED/b9ttgKKRmTB1rXyxl0 Yk3fvcveRf0V61ASXY2kwsxZynOUWmsgZB8gnMVO6K0iXy1Alw/3T6oWt5FDi/nc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h= message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references; s=thelastpickle.com; bh=u/fc2LSl1CYZmCTR3Ddrh98hTnE=; b=cX164n+ GdpFIU9b6IVjWrirUQ2F4ETwL9Tq1/rQKUki4mZPKqwNob/ob+FH/rLNaiX7zSi/ 3vRl9UO2lKarB97NmlbcTQ8b81eBQTdUspCL2K2RwbRC88kE3k/0UuweS6hWjP/C bXC/Jt9SVHHDkuxIYgSbECrWwxfzz5NL5twg= Received: from [10.0.1.151] (121-73-157-230.cable.telstraclear.net [121.73.157.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a44.g.dreamhost.com (Postfix) with ESMTPSA id A7E0C118060 for ; Sat, 25 Sep 2010 20:21:00 -0700 (PDT) Message-Id: From: Aaron Morton To: "user@cassandra.apache.org" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1-73896184 Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (7B500) Mime-Version: 1.0 (iPad Mail 7B500) Subject: Re: LongType from user input Date: Sun, 26 Sep 2010 16:20:57 +1300 References: X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-1-73896184 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Things a changing in v0.7, the row keys are byte arrays. Not sure I understand your other concerns.=20 Aaron On 25 Sep 2010, at 08:10, Christian Decker = wrote: > Thanks for your quick answer, I think I'll use an affix to sort of = cast the keys, ranges and others from their textual representation (from = Pig) to the desired byte representation, since I just noticed that the = keys for the rows themselfs are always UTF8 interpreted, and since I = want to make key-range as well as slice queries, I'll be better off this = way I think. I'll just add a 'L' for Long and 'U' for UUID (of any = kind). > Or is there a better way that I just can't see from my beginners = angle? :-)thing >=20 > Regards, > Chris >=20 >=20 > On Fri, Sep 24, 2010 at 6:35 PM, Tyler Hobbs = wrote: > Yes, you can use describe_keyspace() and then look through the = results. It's a little ugly in 0.6, but it works. >=20 > - Tyler >=20 >=20 > On Fri, Sep 24, 2010 at 11:25 AM, Christian Decker = wrote: > Well I'm writing a loading function for Pig, and as it happens I want = to be able to load slices from cassandra which are specified in the pig = script (thus the input from stdin) but the ColumnFamily from which to = read the data is another parameter and some of the CFs have UTF8, UUID, = TimeUUID or Long types for their keys and columns, so simply converting = everything I get to an 8byte long would break compatibility with the = others. > Now thinking about it I attacked the whole problem in a weird way, = since UUID types won't work either. > So let me change my question slightly, is there a way in 0.6 to detect = the compareWith type on a running cluster? That way I could convert it = to the right type :D >=20 > Regards, > Chris >=20 > On Fri, Sep 24, 2010 at 6:09 PM, Tyler Hobbs = wrote: > I'm not sure I understand why using this with multiple column families = prevents you from converting it. Could you clarify this? >=20 >=20 > On Fri, Sep 24, 2010 at 10:56 AM, Christian Decker = wrote: > Hi all, >=20 > I'm having quite a dilemma with the CompareWith attribute. The Problem = is that I have numeric IDs that I'd like to use as row keys, only that I = also have to offer a possibility to let users input them from std input. = Since I cannot ask my users to input an 8byte sequence representing the = ID they'd like, I was about to turn to UTF8, when I remembered that they = are compared lexicographically, so that 100 actually comes before 2, = which kills key slices. Also I cannot just code a converter in since = this is supposed to be a used with multiple columnfamilies, so just = converting an integer read into 8bytes isn't going to work either. > Any tricks for this one? >=20 > Regards, > Chris >=20 >=20 >=20 >=20 --Apple-Mail-1-73896184 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Things a changing in v0.7, the row keys are byte arrays.

Not sure I understand your other concerns. 

Aaron

On 25 Sep 2010, at 08:10, Christian Decker <decker.christian@gmail.com> wrote:

Thanks for your quick answer, I think I'll use an affix to sort of cast the keys, ranges and others from their textual representation (from Pig) to the desired byte representation, since I just noticed that the keys for the rows themselfs are always UTF8 interpreted, and since I want to make key-range as well as slice queries, I'll be better off this way I think. I'll just add a 'L' for Long and 'U' for UUID (of any kind).
Or is there a better way that I just can't see from my beginners angle? :-)thing

Regards,
Chris


On Fri, Sep 24, 2010 at 6:35 PM, Tyler Hobbs <tyler@riptano.com> wrote:
Yes, you can use describe_keyspace() and then look through the results.  It's a little ugly in 0.6, but it works.

- Tyler


On Fri, Sep 24, 2010 at 11:25 AM, Christian Decker <decker.christian@gmail.com> wrote:
Well I'm writing a loading function for Pig, and as it happens I want to be able to load slices from cassandra which are specified in the pig script (thus the input from stdin) but the ColumnFamily from which to read the data is another parameter and some of the CFs have UTF8, UUID, TimeUUID or Long types for their keys and columns, so simply converting everything I get to an 8byte long would break compatibility with the others.
Now thinking about it I attacked the whole problem in a weird way, since UUID types won't work either.
So let me change my question slightly, is there a way in 0.6 to detect the compareWith type on a running cluster? That way I could convert it to the right type :D

Regards,
Chris

On Fri, Sep 24, 2010 at 6:09 PM, Tyler Hobbs <tyler@riptano.com> wrote:
I'm not sure I understand why using this with multiple column families prevents you from converting it.  Could you clarify this?


On Fri, Sep 24, 2010 at 10:56 AM, Christian Decker <decker.christian@gmail.com> wrote:
Hi all,

I'm having quite a dilemma with the CompareWith attribute. The Problem is that I have numeric IDs that I'd like to use as row keys, only that I also have to offer a possibility to let users input them from std input. Since I cannot ask my users to input an 8byte sequence representing the ID they'd like, I was about to turn to UTF8, when I remembered that they are compared lexicographically, so that 100 actually comes before 2, which kills key slices. Also I cannot just code a converter in since this is supposed to be a used with multiple columnfamilies, so just converting an integer read into 8bytes isn't going to work either.
Any tricks for this one?

Regards,
Chris




--Apple-Mail-1-73896184--