Provide timestamp column access about cassandra

[ryanking]

I'm not opposed to this, but since its not a priority for us, all I can contribute is design help/review. If you'd like to tackle it I can help sort out a design.

[mperham]

If you want to give me commit access, I'd be happy to work on an API + tests with your suggestions.

[ryanking]

I'd prefer to use github's fork and pull model for development.

[IcyMidnight]

Based on the commit log and this issue being open, it doesn't seem this has been added. Are you still planning to look into this Mike? If not perhaps I can make an attempt myself.

[mperham]

I spent an hour or two on it but it was a fairly large API change and I doubt I will have time to on it more. Feel free to work on it.

[siggy]

Pull request sent for:
http://github.com/siggy/cassandra/commit/439ce611a1c6d15574b47780bd34d174b124dc9b

API backwards compatibility is preserved. However, enabling the new 'timestamp' option will alter the data structure returned.

>> twitter.get(:Statuses, "1")
=> #<OrderedHash {"text"=>"Nom nom nom nom nom.", "user_id"=>"5"}>
>> twitter.get(:Statuses, "1", :timestamp => true)
=> #<OrderedHash {"text"=>{"timestamp"=>1273096932561890, "value"=>"Nom nom nom nom nom."}, "user_id"=>{"timestamp"=>1273096932561890, "value"=>"5"}}>

Comments/suggestions?

[mperham]

Nice!

Only thing I can think of would be an option to convert those timestamps to actual Ruby objects, rather than just raw integers. I guess if all you want to do is compare timestamps, it's not necessary.

[ryanking]

@mperham -

I assume you're talking about converting the timestamps to Time objects...

In cassandra, "timestamp" means "long that represents something like time" and not everyone uses it the same way, so I say we should just expose it as an int.

[evan]

It is probably okay to consistently cast Timestamps in our client. People who use multiple clients will probably know what they're doing.

If you're going to use the deep hash response API, timestamp and value should be symbols.

Would it make sense to subclass String for the column names, and decorate it with an additional timestamp accessor? That way backwards compatibility could be preserved. Or maybe an explicit column struct would be better.

[ryanking]

Maybe we should extend OrderdHash with at timestamps method, so that you can do

twitter.get(:Statuses, "1").timestamps[:text] =>1273096932561890

[mrflip]

+1 to extending OrderedHash with a timestamps method rather than using the nested hash.

[tomafro]

+1 from me also. If this isn't being worked on by anyone, I am happy to give it a go over the next fortnight

[ryanking]

Looks like this is dead?

[mperham]

I no longer need this functionality. I'll defer to others.

[tomafro]

Yeah, sorry. I looked in to adding it (seemed pretty easy), but quickly realised I had no real need for it.

[siggy]

Pull request sent for:
http://github.com/siggy/cassandra/commit/87276cf3c44e89a1e1a5d3d8c3d064da85f2db47

OrderedHash::timestamps is itself a hash (unordered for RUBY_VERSION < 1.9):

>> twitter.get(:Statuses, "1").timestamps
=> {"text"=>1282724889876849, "user_id"=>1282724889876849} 

>> twitter.get(:Statuses, "2").timestamps
=> {"reply_to_id"=>1282724889881382, "text"=>1282724889881382, "user_id"=>1282724889881382}

[ryanking]

merged siggy's work. boom!