If I use : <TimestampOfDueTimeInFuture>: <UserId> : <ReminderCountOfThisUser> as key pattern for the rows of reminders, then I am storing the key, just as it is, as the column name and thus column values need not contain a link to the row containing the reminder details.
I think UserId would be required along with timestamp in the key pattern to provide uniqueness to the key as there may be several reminders generated by users on the application, at the same time. But my question is about whether it is really advisable to even generate the keys like this pattern ... instead of going with timeuuids ? Are there are any downsides which I am not perhaps not aware of ? On Thu, Feb 3, 2011 at 5:43 PM, Sylvain Lebresne <sylv...@datastax.com> wrote: > On Thu, Feb 3, 2011 at 11:27 AM, Aditya Narayan <ady...@gmail.com> wrote: >> >> Hey all, >> >> I want to store some columns that are reminders to the users on my >> application, in time sorted order in a row(timeline row of the user). >> >> Would it be recommended to store these reminder columns in the >> timeline row with column names like: combination of timestamp(of time >> when the reminder gets due) + UserId+ Reminders Count of that user; >> Column Name= <TimestampOfDueTimeInFuture>: <UserId> : >> <ReminderCountOfThisUser> > > If you have one row by user (which is a good idea), why keep the UserId in > the column name ? > >> >> Then what comparator could I use to sort them in order of the their >> due time ? This comparator should be able to sort no. in descending >> order.(I guess ascii type would do the opposite order) (Reminders need >> to be sorted in the timeline in the order of their due time.) > > *The* solution is write a custom comparator. > Have a look at http://www.datastax.com/docs/0.7/data_model/column_families > and http://www.sodeso.nl/?p=421 for instance. > > As a side note, the fact that the comparator sort in ascending order when > you > need descending order would be that much of a problem, since you can always > do slice queries in reversed order. But even then, asciiType is not a very > satisfying solution as you would have to be careful about the padding of > your > timestamp for it to work correctly. So again, custom comparator is the way > to go. >> >> Basically I am trying to avoid 16 bytes long timeUUID first because >> they are too long and the above defined key pattern is guaranteeing me >> a unique key/Id for the reminder row always. >> >> >> Thanks >> Aditya Narayan > > -- > Sylvain
