Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 60128 invoked from network); 31 Aug 2010 14:28:10 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 31 Aug 2010 14:28:10 -0000 Received: (qmail 32415 invoked by uid 500); 31 Aug 2010 14:28:08 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 32094 invoked by uid 500); 31 Aug 2010 14:28:05 -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 32086 invoked by uid 99); 31 Aug 2010 14:28:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Aug 2010 14:28:04 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tmarthinussen@gmail.com designates 209.85.160.44 as permitted sender) Received: from [209.85.160.44] (HELO mail-pw0-f44.google.com) (209.85.160.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Aug 2010 14:27:57 +0000 Received: by pwi1 with SMTP id 1so3035067pwi.31 for ; Tue, 31 Aug 2010 07:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:references:from :content-type:x-mailer:in-reply-to:message-id:date:to :content-transfer-encoding:mime-version; bh=b5h4O7oljKQ0b7YuJNASwEPr4qq11WizoD3n6HOfaHM=; b=RS1Wp8KCAlubwaueKugny2TlU7jVK8FmSPHL5OxlEduFN7zubSSTXdPzB4NG6zrhsn 4s/WvxzEAjm/HRnCvmdMFO4MQmSeA4W7u+zy4pRHGz9GgVzPdUxrMNS1vev3VH63Qz83 XM2P9LrgASuId+4x/Gc6atfGhF14PvsDBcVlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; b=MFF5zspy9rb+fH+EMPvLHvNF25kfCIxBHOk6g+LxhBRHrN5PL0ZybZcvtZijHGBM9u cW/WzQvKLP6g8NicPFKldiyzcDV28oJQ1PNpnXu8GCQQN8r/Cp/A5NM0kTrRrr718+GO GqzxKs0Vbtg4O3m20XecdXkxrfpUxwlgCGwZY= Received: by 10.142.83.12 with SMTP id g12mr5864125wfb.173.1283264855871; Tue, 31 Aug 2010 07:27:35 -0700 (PDT) Received: from [126.248.241.61] (pw126248241061.8.tss.panda-world.ne.jp [126.248.241.61]) by mx.google.com with ESMTPS id k23sm10022379wfa.5.2010.08.31.07.27.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 31 Aug 2010 07:27:35 -0700 (PDT) Subject: Re: column family names References: <968b952c-6621-ca3d-af24-974b81e174f7@me.com> <21AE7234-13D9-4315-8A0E-AA81B927A678@ecyrd.com> From: Terje Marthinussen Content-Type: multipart/alternative; boundary=Apple-Mail-1-14940724 X-Mailer: iPhone Mail (8A306) In-Reply-To: Message-Id: Date: Tue, 31 Aug 2010 23:26:52 +0900 To: "user@cassandra.apache.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 8A306) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-1-14940724 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sure, but as I am likely to have multiple clients (which I may not control) a= ccessing a single store, I would prefer to keep such custom mappings out of t= he client for consistency reasons (much bigger problem than any of the opera= tional issues highlighted so far). Terje =20 On 31 Aug 2010, at 23:03, David Boxenhorn wrote: > It's not so hard to implement your mapping suggestion in your application,= rather than in Cassandra, if you really want it.=20 >=20 > On Tue, Aug 31, 2010 at 1:05 PM, Terje Marthinussen wrote: > No benefit? > Making it easier to use column families as part of your data model is a fa= irly good benefit, at least given the somewhat special data model cassandra o= ffers. Much more of a benefit than the disadvantages I can imagine. >=20 > fileprefix=3D`sometool -fileprefix tablename` > is something I would say is a lot more unixy than windows like. >=20 > Sorry, I don't share your concern for large scale operations here, but sur= e, '_' does the trick for me now so thanks to Aaron for reminding me about t= hat. >=20 > Some day I am sure there will be realized that unicode strings/byte arrays= are useful here like most other places in Cassandra (\w is a bit limited fo= r some of us living in the non-ascii part of the world...), but "what is the= XXX way" are not the type of topics I find interesting, so another time. >=20 > Terje >=20 >=20 >=20 > On Tue, Aug 31, 2010 at 5:30 PM, Benjamin Black wrote: > This is not the Unix way for good reason: it creates all manner of > operational challenges for no benefit. This is how Windows does > everything and automation and operations for large-scale online > services is _hellish_ because of it. This horse is sufficiently > beaten, though. >=20 >=20 > b >=20 > On Mon, Aug 30, 2010 at 11:55 PM, Terje Marthinussen > wrote: > > Another option would of course be to store a mapping between dir/filenam= es > > and Keyspace/columns familes together with other info related to keyspac= es > > and column families. Just add API/command line tools to look up the > > filenames and maybe store the values in the files as well for recovery > > purposes. > > > > Terje > > > > On Tue, Aug 31, 2010 at 3:39 PM, Janne Jalkanen > > wrote: > >> > >> I've been doing it for years with no technical problems. However, using= > >> "%" as the escape char tends to, in some cases, confuse a certain opera= ting > >> system whose name may or may not begin with "W", so using something els= e > >> makes sense. > >> However, it does require an extra cognitive step for the maintainer, si= nce > >> the mapping between filenames and logical names is no longer immediatel= y > >> obvious. Especially with multiple files this can be a pain (e.g. Chines= e > >> logical names which map to pretty incomprehensible sequences that are > >> laborious to look up). > >> So my experience suggests to avoid it for ops reasons, and just go with= > >> simplicity. > >> /Janne > >> On Aug 31, 2010, at 08:39 , Terje Marthinussen wrote: > >> > >> Beyond aesthetics, specific reasons? > >> > >> Terje > >> > >> On Tue, Aug 31, 2010 at 11:54 AM, Benjamin Black wrote: > >>> > >>> URL encoding. > >>> > >> > > > > >=20 >=20 --Apple-Mail-1-14940724 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Sure, but as I am likely to have multiple clients (which I may not control) accessing a single store, I would prefer to keep such custom mappings out of the client for consistency reasons (much bigger problem than any of the operational issues highlighted so far).

Terje  

On 31 Aug 2010, at 23:03, David Boxenhorn <david@lookin2.com> wrote:

It's not so hard to implement your mapping suggestion in your application, rather than in Cassandra, if you really want it.

On Tue, Aug 31, 2010 at 1:05 PM, Terje Marthinussen <tmarthinussen@gmail.com> wrote:
No benefit?
Making it easier to use column families as part of your data model is a fairly good benefit, at least given the somewhat special data model cassandra offers. Much more of a benefit than the disadvantages I can imagine.

fileprefix=`sometool -fileprefix tablename`
is something I would say is a lot more unixy than windows like.

Sorry, I don't share your concern for large scale operations here, but sure, '_' does the trick for me now so thanks to Aaron for reminding me about that.

Some day I am sure there will be realized that unicode strings/byte arrays are useful here like most other places in Cassandra (\w is a bit limited for some of us living in the non-ascii part of the world...), but "what is the XXX way" are not the type of topics I find interesting, so another time.

Terje



On Tue, Aug 31, 2010 at 5:30 PM, Benjamin Black <b@b3k.us> wrote:
This is not the Unix way for good reason: it creates all manner of
operational challenges for no benefit.  This is how Windows does
everything and automation and operations for large-scale online
services is _hellish_ because of it.  This horse is sufficiently
beaten, though.


b

On Mon, Aug 30, 2010 at 11:55 PM, Terje Marthinussen
<tmarthinussen@gmail.com> wrote:
> Another option would of course be to store a mapping between dir/filenames
> and Keyspace/columns familes together with other info related to keyspaces
> and column families. Just add API/command line tools to look up the
> filenames and maybe store the values in the files as well for recovery
> purposes.
>
> Terje
>
> On Tue, Aug 31, 2010 at 3:39 PM, Janne Jalkanen <Janne.Jalkanen@ecyrd.com>
> wrote:
>>
>> I've been doing it for years with no technical problems. However, using
>> "%" as the escape char tends to, in some cases, confuse a certain operating
>> system whose name may or may not begin with "W", so using something else
>> makes sense.
>> However, it does require an extra cognitive step for the maintainer, since
>> the mapping between filenames and logical names is no longer immediately
>> obvious. Especially with multiple files this can be a pain (e.g. Chinese
>> logical names which map to pretty incomprehensible sequences that are
>> laborious to look up).
>> So my experience suggests to avoid it for ops reasons, and just go with
>> simplicity.
>> /Janne
>> On Aug 31, 2010, at 08:39 , Terje Marthinussen wrote:
>>
>> Beyond aesthetics, specific reasons?
>>
>> Terje
>>
>> On Tue, Aug 31, 2010 at 11:54 AM, Benjamin Black <b@b3k.us> wrote:
>>>
>>> URL encoding.
>>>
>>
>
>


--Apple-Mail-1-14940724--