LensRegistry does not allow registered items to be accessed within current txn #1592
Assignees
Labels
Comments
AndrewSisley
added
bug
This was referenced Jun 26, 2023
AndrewSisley
added a commit
that referenced
this issue
Aug 3, 2023
## Relevant issue(s) Resolves #1649 #1592 ## Description Improves the way migrations handle transactions, as well as fixing a couple of concurrency issues: - Adds locks around the various registry properties, these maps can be accessed concurrently and need to be protected. - Removes the transaction continuity issue in the client.LenRegistry interface, where db.LensRegistry() returns an object that does not respect the transactionality of the parent store, and takes `txn`s as input parameters to some of its functions. It does this by following the same pattern as `db.db`. (#1649) - Fixes the bugs in the lens package where migrations set were not visible/accessible until after commit. They are now visible within the transaction scope. (#1592) It still does not provide transaction snapshot isolation, I see that issue as relatively high effort low reward at the moment.
shahzadlone
pushed a commit
to shahzadlone/defradb
that referenced
this issue
Feb 23, 2024
## Relevant issue(s) Resolves sourcenetwork#1649 sourcenetwork#1592 ## Description Improves the way migrations handle transactions, as well as fixing a couple of concurrency issues: - Adds locks around the various registry properties, these maps can be accessed concurrently and need to be protected. - Removes the transaction continuity issue in the client.LenRegistry interface, where db.LensRegistry() returns an object that does not respect the transactionality of the parent store, and takes `txn`s as input parameters to some of its functions. It does this by following the same pattern as `db.db`. (sourcenetwork#1649) - Fixes the bugs in the lens package where migrations set were not visible/accessible until after commit. They are now visible within the transaction scope. (sourcenetwork#1592) It still does not provide transaction snapshot isolation, I see that issue as relatively high effort low reward at the moment.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
E.g. If a transaction is explicitly passed into
RegisterLens, and that txn is not commited, and then also used to query the database, then the migration registered will not be accessible to the query.See
TestSchemaMigrationQueryWithTxnandTestSchemaMigrationGetMigrationsWithTxnfor tested examples.The same issue also affects
parser.SetSchema, which is also missing tests for this.The text was updated successfully, but these errors were encountered: