A use case that could use this (but isn't in my top requests) is usage history for a given user. I use a single row to save history per user, each column is a user action with name a TimeUUID and value is a blob. I use the TimeUUID to sort the actions, but I don't really care about exact time. after the number of user actions exceeds a threshold, I want to remove enough to bring the actions back below the threshold. I could model this as you say and remove chunks of actions by deleting a row, but that is more cumbersome for the client.
The reason this isn't in my top requests is regardless if the client or the server performs this sort of delete, the row must first be read. By having the server do it, a network hop is saved as well as implementing a common usage pattern. On 11/5/11 2:45 PM, "Brandon Williams" <dri...@gmail.com> wrote: >On Fri, Nov 4, 2011 at 9:50 PM, Jim Newsham <jnews...@referentia.com> >wrote: >> Our use case is time-series data (such as sampled sensor data). Each >>row >> describes a particular statistic over time, the column name is a time, >>and >> the column value is the sample. So it makes perfect sense to want to >>delete >> columns for a given time range. I'm sure there must be numerous other >>use >> cases for which using a range of column names makes sense. > >Assuming you are bucketing your rows at some interval (as in >http://rubyscale.com/2011/basic-time-series-with-cassandra/), why is >deleting the entire row for the interval not acceptable? > >-Brandon
