You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Ted Zlatanov <tz...@lifelogs.com> on 2010/03/18 17:45:58 UTC

renaming a SuperColumn

I find it useful in one particular schema to have SuperColumns with
specific names and rename them sometimes.  Rather than client-side
(read, write, delete) it would be nice if there was a SuperColumnRename
Mutation than encapsulated that sequence on the server side and perhaps
implemented it more efficiently.  Right now I pay a pretty high cost for
the client roundtrips and this would make my writers much more
efficient.  I don't need it to be atomic.

Is this feasible and has it been discussed before?

Thanks
Ted


Re: renaming a SuperColumn

Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 18 Mar 2010 19:26:06 +0100 Sylvain Lebresne <sy...@yakaz.com> wrote: 

SL> Given how Cassandra works, I don't think that the server can do much
SL> better than the read, write, delete your client already do
SL> (basically everything is immutable, you only 'add' new versions). As
SL> this cannot be done efficiently (I can be wrong on that but if so, I
SL> *really* would be interested to know why), a model that require a
SL> lot of renames of SuperColumn is probably not a super good fit for
SL> Cassandra (I'm not sure why you need a lot of rename though, maybe
SL> you really have no choice).  So I lean in the same direction as
SL> Jonathan. Adding an API call that 'promote' an operation not very
SL> efficient is not a good idea.

Thanks for explaining, Sylvain.

I could go into details about my model but it's not so important (it's
evolving as I find the best fit between the model and Cassandra).  As
long as I know Cassandra is not a good fit for this kind of operation I
can design a better data model.

Ted


Re: renaming a SuperColumn

Posted by Sylvain Lebresne <sy...@yakaz.com>.
2010/3/18 Ted Zlatanov <tz...@lifelogs.com>:
> On Thu, 18 Mar 2010 11:50:53 -0500 Jonathan Ellis <jb...@gmail.com> wrote:
>
> JE> 2010/3/18 Ted Zlatanov <tz...@lifelogs.com>:
>>> I find it useful in one particular schema to have SuperColumns with
>>> specific names and rename them sometimes.  Rather than client-side
>>> (read, write, delete) it would be nice if there was a SuperColumnRename
>>> Mutation than encapsulated that sequence on the server side and perhaps
>>> implemented it more efficiently.  Right now I pay a pretty high cost for
>>> the client roundtrips and this would make my writers much more
>>> efficient.  I don't need it to be atomic.
>>>
>>> Is this feasible and has it been discussed before?
>
> JE> -1 on adding a special case for this.
>
> Is it really uncommon or wrong (in Cassandra's data model) to want to
> rename a SuperColumn?  It seems genuinely useful to me, so I must be
> missing something obvious.  Or is the problem with the code complexity
> and bugs it could spawn?

Given how Cassandra works, I don't think that the server can do much better
than the read, write, delete your client already do (basically everything is
immutable, you only 'add' new versions). As this cannot be done efficiently (I
can be wrong on that but if so, I *really* would be interested to know why), a
model that require a lot of renames of SuperColumn is probably not a super
good fit for Cassandra (I'm not sure why you need a lot of rename though, maybe
you really have no choice).
So I lean in the same direction as Jonathan. Adding an API call that
'promote' an
operation not very efficient is not a good idea.

--
Sylvain

Re: renaming a SuperColumn

Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 18 Mar 2010 11:50:53 -0500 Jonathan Ellis <jb...@gmail.com> wrote: 

JE> 2010/3/18 Ted Zlatanov <tz...@lifelogs.com>:
>> I find it useful in one particular schema to have SuperColumns with
>> specific names and rename them sometimes.  Rather than client-side
>> (read, write, delete) it would be nice if there was a SuperColumnRename
>> Mutation than encapsulated that sequence on the server side and perhaps
>> implemented it more efficiently.  Right now I pay a pretty high cost for
>> the client roundtrips and this would make my writers much more
>> efficient.  I don't need it to be atomic.
>> 
>> Is this feasible and has it been discussed before?

JE> -1 on adding a special case for this.

Is it really uncommon or wrong (in Cassandra's data model) to want to
rename a SuperColumn?  It seems genuinely useful to me, so I must be
missing something obvious.  Or is the problem with the code complexity
and bugs it could spawn?

Ted


Re: renaming a SuperColumn

Posted by Vijay <vi...@gmail.com>.
+1 for renaming the S Column/Column as a atomic operation :)

Regards,
</VJ>



On Thu, Mar 18, 2010 at 9:50 AM, Jonathan Ellis <jb...@gmail.com> wrote:

> -1 on adding a special case for this.
>
> 2010/3/18 Ted Zlatanov <tz...@lifelogs.com>:
> > I find it useful in one particular schema to have SuperColumns with
> > specific names and rename them sometimes.  Rather than client-side
> > (read, write, delete) it would be nice if there was a SuperColumnRename
> > Mutation than encapsulated that sequence on the server side and perhaps
> > implemented it more efficiently.  Right now I pay a pretty high cost for
> > the client roundtrips and this would make my writers much more
> > efficient.  I don't need it to be atomic.
> >
> > Is this feasible and has it been discussed before?
> >
> > Thanks
> > Ted
> >
> >
>

Re: renaming a SuperColumn

Posted by Jonathan Ellis <jb...@gmail.com>.
-1 on adding a special case for this.

2010/3/18 Ted Zlatanov <tz...@lifelogs.com>:
> I find it useful in one particular schema to have SuperColumns with
> specific names and rename them sometimes.  Rather than client-side
> (read, write, delete) it would be nice if there was a SuperColumnRename
> Mutation than encapsulated that sequence on the server side and perhaps
> implemented it more efficiently.  Right now I pay a pretty high cost for
> the client roundtrips and this would make my writers much more
> efficient.  I don't need it to be atomic.
>
> Is this feasible and has it been discussed before?
>
> Thanks
> Ted
>
>