platinumhamburg commented on PR #3621:
URL: https://github.com/apache/fluss/pull/3621#issuecomment-4947110504

   > Row TTL touches encoding, snapshot reads, lookups, and Flink conversion, 
so the intended expiration boundary would be helpful to state explicitly in the 
PR description. Is a row considered expired when `currentTime == 
expirationTime`, and is the decision based on a server-supplied clock or the 
reading client’s clock? A focused test around the exact boundary, including a 
snapshot created before expiry but read after expiry, would make the behavior 
easier to preserve across scanners.
   
   Hi @hiSandog , thanks for your suggestion, the documentation changes in the 
PR explicitly define TTL as a best-effort mechanism rather than providing 
precise expiration guarantees. There is no commitment to immediate expiration 
once the time threshold is crossed (i.e., we will not perform additional 
row-level visibility filtering strictly for TTL semantics, as this would 
generally exceed typical user requirements and incur significant performance 
overhead). Furthermore, the expiration decision is explicitly based on the 
server clock. For scenarios involving event-time TTL, the TTL configuration 
must clearly specify either precise timezone semantics or an exact timestamp.


-- 
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]

Reply via email to