It's best to just use timestamps as the current millisecond (or better) time and treat them as an internal implementation thing for cassandra. Playing with them will only bring you pain.
As Phil says when applying a mutation, if the time stamp is less than the current value cassandra will ignore the mutation.
You are sort of on the right track, try something like a Super CF called UserHistory
key is the user id
super column for every SKU the user has purchased
in each super column, a column for every purchase of the sku. Column name is a TimeUUID column value is the OrderId.
When an order is placed include updating the UserHistory CF in your batch_mutation. There is no need to check if it already exists.
To get the first purchase of a SKU do a get_slice using the SliceRange to specify you want 1 column and seting start and finish to "".
But, it may be efficient to just pull back the entire row for the user (the whole purchase history). You'll get things in order so you can still know what the first purchase for every SKU is. Or you can sort them in your code.
It's better to make fewer calls that return more data using less CF's. For example you may want to consider collapsing the UserHistory and (i guess) User CF into one CF if you often want to get those two things at the same time.
Hope that helps.
On 22 Sep, 2010,at 07:39 AM, Phil Stanhope <email@example.com> wrote:
My experience is that timestamps have to be sequentially increasing for writes to work. Soft/silent error if you do not follow this protocol. Haven't tested against > 0.6.4 though.
On Tue, Sep 21, 2010 at 8:29 AM, Lucas Nodine <firstname.lastname@example.org>
Chris, I believe if the timestamp being written if the same or older it will not apply the write, but do not quote me on this, test it. In this case, if the timestamp value does not matter, you could simply always write with a timestamp of 1.
On Tue, Sep 21, 2010 at 5:58 AM, Christian Decker <email@example.com>
I have a rather strange problem I'd like to address. As I understand it a write in cassandra always overwrites already existing data, so it is not possible to have a way to create an index pointing to the first entry matching some criteria. What I mean is that I have a CF which stores user purchases and now I want to find the first time a user bought an item from a certain class of objects. For this I was thinking about a CF with SCFs, the CF key being the user ID and the SCF key being the class id of the item and then the value would be the key of the purchase in the purchases CF Obviously for this to work I'd have to check if a value like firstPurchases already exists and if not write it, but it there a way to implement it without the additional read?
Lucas J. Nodine
Assistant Labette County Attorney
201 S. Central, Suite B
Parsons, KS 67357