bereng commented on code in PR #1891:
URL: https://github.com/apache/cassandra/pull/1891#discussion_r1187201435
##########
src/java/org/apache/cassandra/db/rows/Cell.java:
##########
@@ -59,16 +70,37 @@
public interface Factory<V>
{
- Cell<V> create(ColumnMetadata column, long timestamp, int ttl, int
localDeletionTime, V value, CellPath path);
+ Cell<V> create(ColumnMetadata column, long timestamp, int ttl, long
localDeletionTime, V value, CellPath path);
}
protected Cell(ColumnMetadata column)
{
super(column);
}
+ public static int deletionTimeLongToUnsignedInteger(long deletionTime)
+ {
+ return deletionTime == NO_DELETION_TIME ?
NO_DELETION_TIME_UNSIGNED_INTEGER : CassandraUInt.fromLong(deletionTime);
+ }
+
+ public static long deletionTimeUnsignedIntegerToLong(int
deletionTimeUnsignedInteger)
+ {
+ return deletionTimeUnsignedInteger ==
NO_DELETION_TIME_UNSIGNED_INTEGER ? NO_DELETION_TIME :
CassandraUInt.toLong(deletionTimeUnsignedInteger);
+ }
+
+ public static long getVersionedMaxDeletiontionTime()
+ {
+ if (BigFormat.ttlMode.equals(TTL_MODE.EXTENDED_TTL_2106))
+ // The whole cluster is 2016, we're out of the 2038/2106 mixed
clusters scenario. Short cut to avoid the 'minClusterVersion' volatile read
Review Comment:
Thx for that commit. I have shamelessly stolen it with some fixed test
failures. Some comments:
- I like the 'generic' spin you gave it which will be nice for 18301
- I like it respects the tri-state. Here we're avoiding a volatile read. But
if 18301 goes TCM or anything else, 99% probability it will be more expensive
than a volatile read, we need a mechanism to avoid that cost in the interim
upgrading state.
- I like it respects the idea of signaling the upgrade having finished and
not having a window of opportunity to go back/forth accidentally.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
