-
Notifications
You must be signed in to change notification settings - Fork 59
support querying next snapshot after a timestamp #3552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 19 commits
dbe7254
79fe68a
e34d096
2c5cccd
b3710e6
e93f1d5
b8280be
3695a03
a9b87eb
4f56201
e4a5415
9b6302c
427efda
24af1f1
02eb6d3
0698fcc
b4a5388
d5ee22a
bb07b6e
c44fcc7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -68,6 +68,34 @@ class AcsSnapshotStore( | |
| .value | ||
| } | ||
|
|
||
| def lookupSnapshotAfter( | ||
| migrationId: Long, | ||
| after: CantonTimestamp, | ||
| )(implicit tc: TraceContext): Future[Option[AcsSnapshot]] = { | ||
|
|
||
| val select = | ||
| sql"select snapshot_record_time, migration_id, history_id, first_row_id, last_row_id, unlocked_amulet_balance, locked_amulet_balance " | ||
| val orderLimit = sql" order by snapshot_record_time asc limit 1 " | ||
| val sameMig = select ++ sql""" from acs_snapshot | ||
| where snapshot_record_time > $after | ||
| and migration_id = $migrationId | ||
| and history_id = $historyId """ ++ orderLimit | ||
| val largerMig = select ++ sql""" from acs_snapshot | ||
| where migration_id > $migrationId | ||
| and history_id = $historyId """ ++ orderLimit | ||
|
|
||
| val query = | ||
| sql"select * from ((" ++ sameMig ++ sql") union all (" ++ largerMig ++ sql")) all_queries order by snapshot_record_time asc limit 1" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A bit complicated for a table with only thousands of rows, but should make optimal use of the available primary key index.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yup, that was my thinking exactly |
||
|
|
||
| storage | ||
| .querySingle( | ||
| query.toActionBuilder.as[AcsSnapshot].headOption, | ||
| "lookupSnapshotAfter", | ||
| ) | ||
| .value | ||
|
|
||
| } | ||
|
|
||
| def insertNewSnapshot( | ||
| lastSnapshot: Option[AcsSnapshot], | ||
| migrationId: Long, | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is different from the
/v0/state/acs/snapshot-timestampendpoint, which only looks at snapshots from exactly the given migration id.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH, I think that the semantics in the existing one is less useful. People don't really care about migration IDs, it's almost an implementation detail. They just want the previous/next snapshot from a specific timestamp.