Repository navigation
fix: Update view version log timestamp for historical accuracy - #1218
Merged
liurenjie1024 merged 2 commits intoApr 18, 2025
Merged
Conversation
Contributor
|
nice find @c-thiel and yes I agree that this seems like a bug that we should also fix on the Java side |
3 tasks
liurenjie1024
approved these changes
Apr 16, 2025
liurenjie1024
left a comment
Contributor
There was a problem hiding this comment.
Thanks @c-thiel for this fix, LGTM!
Contributor
|
Let's wait for a while for @Fokko 's response. |
Contributor
|
Agree, this seems like the desired behaviour. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes are included in this PR?
This change updates the behavior when setting a view version as current. When we set a previously existing view version as current, we now update its log timestamp to the current time rather than reusing the original timestamp of the ViewVersion.
Lets assume the following changes:
This resulted in the following
version_log:Note that the last and first entries have the same timestamp, namely the time stamp of the initial ViewVersion creation.
I believe this is undesired in a history, where we are interested when a certain change became active. It makes sense to use the exact timestamp of the ViewVersion if it was added in the same set of changes, but re-enabling a previously used view version (maybe years ago) should not add a history for this past timestamp.
Java behaviors the same way as rust currently does. @Fokko @nastra if we agree that we should change the behavior, we should also touch Java.
Are these changes tested?
Yes