Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of eran@gigya-inc.com designates
 209.85.160.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <e06563881003041403o3963edfqc1092a7b7e40d7c3@mail.gmail.com>
References: <66b0df0b1003020443i71f87c6fl443cb0a51c94e14f@mail.gmail.com>
	<e06563881003020544q1bc4f71ax95973efdd837b5c2@mail.gmail.com>
	<66b0df0b1003040051j74f758a4odb4896584bc7c9fc@mail.gmail.com>
	<e06563881003041403o3963edfqc1092a7b7e40d7c3@mail.gmail.com>
From: Eran Kutner <eran@gigya-inc.com>
Date: Fri, 5 Mar 2010 13:11:46 +0200
Message-ID: <66b0df0b1003050311rbec53ybb1e1161bb6ef706@mail.gmail.com>
Subject: Re: Questions while evaluating Cassandra
To: cassandra-user@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Jonathan!


On Fri, Mar 5, 2010 at 00:03, Jonathan Ellis <jbellis@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 2:51 AM, Eran Kutner <eran@gigya-inc.com> wrote:
>> On Tue, Mar 2, 2010 at 15:44, Jonathan Ellis <jbellis@gmail.com> wrote:
>>>
>>> On Tue, Mar 2, 2010 at 6:43 AM, Eran Kutner <eran@gigya.com> wrote:
>>> > Is the procedure described in the description of ticket CASSANDRA-44 =
really
>>> > the way to do schema changes in the latest release? I'm not sure what=
's your
>>> > thoughts about this but our experience is that every release of our s=
oftware
>>> > requires schema changes because we add new column families for indexe=
s.
>>>
>>> Yes, that is how it is for 0.5 and 0.6. =A00.7 will add online schema
>>> changes (i.e., fix -44), Gary is working on that now.
>>
>> So just to be clear, that would require a complete cluster restart as
>> well as stopping the client app (to prevent new writes from coming in
>> after doing the flush), right? Do you know how others are handling it
>> on a live system?
>
> If you're just adding new CFs then you don't need to worry about the
> commitlog. =A0So in production just leave the old ones defined and
> remove the data files from the FS, client doesn't have to care, and
> you can do a rolling restart of your cassandra nodes.
>
>>> DatacenterShardStrategy will put multiple replicas in each DC, for use
>>> with CL.DCQUORUM, that is, a majority of replicas in the same DC as
>>> the coordinator node for the current request. =A0DCQOURUM is not yet
>>> finished, though; currently it behaves the same as CL.ALL.
>>
>> Is it planned for any specific release?
>
> It's planned as soon as someone wants it badly enough to finish it. :)
>
>>> The short answer is, we maintained backwards compatibility for 0.4 ->
>>> 0.5 -> 0.6, but we are going to break things in 0.7 moving from String
>>> keys to byte[] and possibly other changes.
>>
>> hmmm... My assumption was that although keys are strings they are
>> still compared as bytes when using the OPP right? That would be the
>> difference between the OPP and the COPP, right? Just confirming
>> because otherwise creating composite keys with different data types
>> may prove problematic.
>
> Right.
>
> -Jonathan
>