2010/3/18 Ted Zlatanov <t...@lifelogs.com>: > On Thu, 18 Mar 2010 11:50:53 -0500 Jonathan Ellis <jbel...@gmail.com> wrote: > > JE> 2010/3/18 Ted Zlatanov <t...@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
