-
Notifications
You must be signed in to change notification settings - Fork 1
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
Refactor API to use iter.Seq2 instead of Iterator[T] #40
Conversation
|
3a554b8
to
c005ce5
Compare
1732d70
to
a201670
Compare
Marking this ready for review. My plan once this is merged is to create v0.3 release and then bump StateDB in cilium/cilium to v0.3 once the Go v1.23 bump is merged (cilium/cilium#34542) |
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.
Nice! Did a first quick pass focused on first commit, will do a second one later
a201670
to
2c354ce
Compare
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 allows iterating over the query results using normal for loops: for obj := range myTable.All(db.ReadTxn()) { ... } Signed-off-by: Jussi Maki <[email protected]>
Switch over to iter.Seq for iterating over maps and sets. Signed-off-by: Jussi Maki <[email protected]>
Add indexing functions for sequences. Signed-off-by: Jussi Maki <[email protected]>
Signed-off-by: Jussi Maki <[email protected]>
Having Watch() and Changes() separately in ChangeIterator may lead to inconsistent usage when change iteration is combined with a write transaction: var changes statedb.ChangeIterator[someObject] wtxn := db.WriteTxn(someTable) for change := range changes { // changes are reflecting the state of objects coming from the previous // Watch(db.ReadTxn()) call below, not the state they're in "wtxn" someTable.Insert(...) } select { case <-changes.Watch(db.ReadTxn()) } The new API makes it easier to be consistent and use the same transaction for the changes and for the writes: var changeIterator statedb.ChangeIterator[someObject] wtxn := db.WriteTxn(someTable) // Give me the unobserved changes up to the "snapshot" of wtxn changes, watch := changeIterator.Next(wtxn) for change := range changes { // changes are reflecting the state of objects coming from the previous // Watch(db.ReadTxn()) call below, not the state they're in "wtxn" someTable.Insert(...) } select { case <-watch: } If the transaction given to Next() is a WriteTxn it will still use the snapshot of committed data for producing the iterator and will ignore the uncommitted data in the transaction. This is needed as the txn might be aborted, which would then reset the revision back and that would mess up the graveyard watermarks as the marked revision would be in the future. Signed-off-by: Jussi Maki <[email protected]>
2c354ce
to
f08b950
Compare
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.
Acking again after latest changes ✔️
Add support for range-funcs by switching the custom iterator types in StateDB and part.Map and part.Set to iter.Seq/Seq2.
This allows iterating over the query results using normal for loops:
This PR also reworks the Changes() API to be easier to use in combination with a WriteTxn:
This is now easier to use in a consistent way when combined with a WriteTxn and making sure we're using the latest
version of the object. Additionally the implementation was changed to specifically use the snapshot of the committed
data and ignore the changes made in the WriteTxn (otherwise we might mark a revision to graveyard that might be reverted
when Abort()'d).