bereng commented on code in PR #1891:
URL: https://github.com/apache/cassandra/pull/1891#discussion_r1186050095
##########
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:
The distinction between `COMPATIBILITY` and `EXTENDED_TTL_2106` does spare
the extra volatile read yes. But also 'freezes' the status of the cluster. If
sbdy starts a 4.0 node by accident or similar things happen the nodes won't be
flapping from on behavior to the other which sounds very dangerous imo. With
`EXTENDED_TTL_2106` only the accidental node will suffer and the rest of the
cluster will be just fine.
I think your proposal for the avoidance of the volatile read, iiuc, will
always hit the volatile when you're >=5.0 and using MAX_TTL (or anything going
beyond 2038) which is quite a common scenario and it will be more common as we
approach 2038.
--
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]
