Jollyplum commented on code in PR #3663:
URL: https://github.com/apache/cassandra/pull/3663#discussion_r1851157813
##########
src/java/org/apache/cassandra/db/Mutation.java:
##########
@@ -150,6 +150,11 @@ public ImmutableCollection<PartitionUpdate>
getPartitionUpdates()
return modifications.values();
}
+ public long getApproxCreatedAtNanos()
+ {
+ return approxCreatedAtNanos;
Review Comment:
Yeah definitely agree that there is still this window(albeit likely much
shorter) between mutation timestamp creation and the approximate time generated
inside the mutation constructor.
At first glance it's quite a bit more fiddly to get some sort of timestamp
pre mutation constructor timestamp and propagate it everywhere, but I can have
a go at taking RequestTime.startedAtNanos or RequestTime.enqueuedAtNanos and
plumbing it through to the mutation constructor everywhere.
We'll also be adding a long in the Mutation object to solve this issue, so
at fairly tiny but non-negligible cost.
Or I suppose slightly alternatively we could try and pull
approxCreatedAtNanos out to just before the write/delete timestamps are
generated, though this has some downstream effects due to it's other use, which
need to be reasoned carefully about.
--
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]
