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 ED1E21090B for ; Mon, 2 Sep 2013 18:45:20 +0000 (UTC) Received: (qmail 1304 invoked by uid 500); 2 Sep 2013 18:45:18 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 1123 invoked by uid 500); 2 Sep 2013 18:45:18 -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 1115 invoked by uid 99); 2 Sep 2013 18:45:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Sep 2013 18:45:17 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of muhammed.dawood@gmail.com designates 209.85.212.46 as permitted sender) Received: from [209.85.212.46] (HELO mail-vb0-f46.google.com) (209.85.212.46) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Sep 2013 18:45:11 +0000 Received: by mail-vb0-f46.google.com with SMTP id p13so3160408vbe.19 for ; Mon, 02 Sep 2013 11:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AR66W2M+jP/safxhpEgkHsHGXjhyf6lb/OKaboa/YBs=; b=qazewhMqxVHajtmrpKX1mg7FnRS2AmjFRHqn+UCfIopcRrlcYwiSfQm2SRZ+o+G4lt j+NWjopkgMeJRS66+ym0B2B+o7FeZ2Ljtut0Px3jGVjO0nBPkxaOGfD34bhNzfe8HYde m5AxQ1eyxclsGstdRygUWUgB0B/zc7R8lCd8E+uZqnp6wiQQRGsNv/KdgNoyYRqYaDCQ O5GbP0rJ1xSXBH3APXdN6J13R2jg0+75tql66Ly14teVf8E0lvfTGfykgnAWos21SbZM gUCfCVH9TAQgzAxq9PzTPbKCNGUpj2uJeQDdTvIfEATz+77qbtI5OoxEuOAjEPMrAlYA cT4g== MIME-Version: 1.0 X-Received: by 10.52.249.50 with SMTP id yr18mr5584871vdc.25.1378147490831; Mon, 02 Sep 2013 11:44:50 -0700 (PDT) Received: by 10.52.180.67 with HTTP; Mon, 2 Sep 2013 11:44:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Sep 2013 00:14:50 +0530 Message-ID: Subject: Re: Versioning in cassandra From: dawood abdullah To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=089e01495490a3b1f604e56af718 X-Virus-Checked: Checked by ClamAV on apache.org --089e01495490a3b1f604e56af718 Content-Type: text/plain; charset=ISO-8859-1 Requirement is like I have a column family say File create table file(id text primary key, fname text, version int, mimetype text, content text); Say, I have few records inserted, when I modify an existing record (content is modified) a new version needs to be created. As I need to have provision to revert to back any old version whenever required. Regards, Dawood On Mon, Sep 2, 2013 at 10:47 PM, Jan Algermissen wrote: > Hi Dawood, > > On 02.09.2013, at 16:36, dawood abdullah > wrote: > > > Hi > > I have a requirement of versioning to be done in Cassandra. > > > > Following is my column family definition > > > > create table file_details(id text primary key, fname text, version int, > mimetype text); > > > > I have a secondary index created on fname column. > > > > Whenever I do an insert for the same 'fname', the version should be > incremented. And when I retrieve a row with fname it should return me the > latest version row. > > > > Is there a better way to do in Cassandra? Please suggest what approach > needs to be taken. > > Can you explain more about your use case? > > If the version need not be a small number, but could be a timestamp, you > could make use of C*'s ordering feature , have the database set the new > version as a timestamp and retrieve the latest one with a simple LIMIT 1 > query. (I'll explain more when this is an option for you). > > Jan > > P.S. Me being a REST/HTTP head, an alarm rings when I see 'version' next > to 'mimetype' :-) What exactly are you versioning here? Maybe we can even > change the situation from a functional POV? > > > > > > Regards, > > > > Dawood > > > > > > > > > > --089e01495490a3b1f604e56af718 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Requirement is like I have a column family say F= ile

create table file(id text primary key, fname text, version int, = mimetype text, content text);

Say, I have few records inserted= , when I modify an existing record (content is modified) a new version need= s to be created. As I need to have provision to revert to back any old vers= ion whenever required.

Regards,
Dawood


On Mon, Sep 2, 2013 at 10:47 PM, Jan Algermissen <= span dir=3D"ltr"><jan.algermissen@nordsc.com> wrote:
Hi Dawood,

On 02.09.2013, at 16:36, dawood abdullah <muhammed.dawood@gmail.com> wrote:

> Hi
> I have a requirement of versioning to be done in Cassandra.
>
> Following is my column family definition
>
> create table file_details(id text primary key, fname text, version int= , mimetype text);
>
> I have a secondary index created on fname column.
>
> Whenever I do an insert for the same 'fname', the version shou= ld be incremented. And when I retrieve a row with fname it should return me= the latest version row.
>
> Is there a better way to do in Cassandra? Please suggest what approach= needs to be taken.

Can you explain more about your use case?

If the version need not be a small number, but could be a timestamp, you co= uld make use of C*'s ordering feature , have the database set the new v= ersion as a timestamp and retrieve the latest one with a simple LIMIT 1 que= ry. (I'll explain more when this is an option for you).

Jan

P.S. Me being a REST/HTTP head, an alarm rings when I see 'version'= next to 'mimetype' :-) What exactly are you versioning here? Maybe= we can even change the situation from a functional POV?


>
> Regards,
>
> Dawood
>
>
>
>


--089e01495490a3b1f604e56af718--