IMHO If you know the time of the event use store the time as a long, rather than a UUID. It will make it easier to get back to a time and make it easier for you to compare columns. TimeUUIDS has a pseudo random part as well as the time part, it could be set to a constant. By why bother if you know the absolute time.
I'm not sure what the ReminderCountOfThisUser is for, and as Sylvain says there is no need for the user name if this is in a row just for the user. Hope that helps. Aaron On 4 Feb 2011, at 01:32, Aditya Narayan wrote: > 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
