[ https://issues.apache.org/jira/browse/CASSANDRA-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132501#comment-14132501 ]
Benedict edited comment on CASSANDRA-7919 at 9/13/14 3:26 AM: -------------------------------------------------------------- I'm also a little uncomfortable making it explicitly a TimeUUID at the client level, since this may mean clients start expecting the exact TimeUUID back with each request also. This would definitely be a bad thing, and prevent almost all of the timestamp optimisation work we have pencilled for 3.0, as we would have to retain its full bytes forever, the least significant bits of which become meaningless after repair, and are 'random' (a hash of interface + time salt), the state space of which will grow linearly with cluster up-time. was (Author: benedict): I'm also a little uncomfortable making it explicitly a TimeUUID at the client level, since this may mean clients start expecting the exact TimeUUID back with each request also. This would definitely be a bad thing, and prevent almost all of the timestamp optimisation work we have pencilled for 3.0, as we would have to retain its full bytes forever, which are half random, the state space of which will grow linearly with cluster up-time. > Change timestamp representation to timeuuid > ------------------------------------------- > > Key: CASSANDRA-7919 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7919 > Project: Cassandra > Issue Type: Improvement > Reporter: T Jake Luciani > Priority: Minor > Fix For: 3.0 > > > In order to overcome some of the issues with timestamps (CASSANDRA-6123) we > need to migrate to a better timestamp representation for cells. > Since drivers already support timeuuid it makes sense to migrate to this > internally (see CASSANDRA-7056) -- This message was sent by Atlassian JIRA (v6.3.4#6332)