bereng commented on code in PR #2464:
URL: https://github.com/apache/cassandra/pull/2464#discussion_r1263565219
##########
src/java/org/apache/cassandra/db/DeletionTime.java:
##########
@@ -195,42 +195,100 @@ public static Serializer getSerializer(Version version)
return legacySerializer;
}
- // Serializer for Usigned Integer ldt
+ /* Serializer for Usigned Integer ldt
+ *
+ * ldt is encoded as a uint in seconds since unix epoch, it can go up o
2106-02-07T06:28:13+00:00 only.
+ * Since mfda is micros since the Unix Epoch with 7 bytes we can encode
2^56 ~= 1142 years. That leaves
+ * 1 free byte we can use to store flags for sentinel values with some
space saving.
+ *
+ * Currently only a flag for the LIVE ldt is being used.
+ */
public static class Serializer implements ISerializer<DeletionTime>
{
+ private final static int IS_LIVE_DELETION = 0x01;
+ // Long.MAX_VALUE sentinel value equivalent in 7bytes
+ public final static long MAX_MFDA = 0xffffffffffffffL;
+
public void serialize(DeletionTime delTime, DataOutputPlus out) throws
IOException
{
- out.writeInt(delTime.localDeletionTimeUnsignedInteger);
- out.writeLong(delTime.markedForDeleteAt());
+ if (delTime.equals(LIVE))
+ out.writeByte(IS_LIVE_DELETION);
+ else
+ {
+ if (delTime.markedForDeleteAt() > MAX_MFDA &&
delTime.markedForDeleteAt() != Long.MAX_VALUE)
+ throw new IOException("Value too high for markForDeleteAt
to encode in 7 bytes: " + delTime.markedForDeleteAt());
Review Comment:
^Icwym, But a MFDA 2000 years into the future shouldn't happen and we should
never hit that throws. We should never have an MFDA for the year 4200. The
current codebase is dead in year 2106 already.
Let me ping @driftx just to double check. Brandon apologies for the ping,
not trying to loop you into the review, but do you think it's reasonable to
never expect a MFDA that high. Or can you think of any scenarios where this
could be a problem?
--
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]
