Safely acquire lock on multiple tables #100
Conversation
rkrage
force-pushed
the
multi-table-locks
branch
3 times, most recently
from
9541a0a to
c9fdfaa
Compare
rkrage
force-pushed
the
multi-table-locks
branch
8 times, most recently
from
4142ddb to
2cfa43d
Compare
rkrage
force-pushed
the
multi-table-locks
branch
2 times, most recently
from
d159713 to
0660b33
Compare
rkrage
force-pushed
the
multi-table-locks
branch
from
0660b33 to
b956bc5
Compare
rkrage
force-pushed
the
multi-table-locks
branch
3 times, most recently
from
953b0a5 to
ef38a88
Compare
rkrage
force-pushed
the
multi-table-locks
branch
from
ef38a88 to
c2e3775
Compare
rkrage
force-pushed
the
multi-table-locks
branch
from
c2e3775 to
da6cced
Compare
|
|
||
| until successfully_acquired_lock | ||
| while ( | ||
| loop do | ||
| # If in a nested context and all of the above checks have passed, |
There was a problem hiding this comment.
Doesn't this effectively mean that if parent_lock_tables is present we could set successfully_acquired_lock to true earlier and not need this break?
There was a problem hiding this comment.
This seems related to your previous comment:
Do we simply skip lock acquisition (as a query, I mean) in that case since we track what we've locked?
Are you suggesting we could short-circuit in a nested lock scenario and just execute the block that was passed in?
There was a problem hiding this comment.
This seems related to your previous comment:
I should have clarified what I was continuing the conversation on; it was this one: #100 (comment)
| attr_reader :raw_set | ||
|
|
||
| delegate :each, to: :raw_set | ||
| delegate :mode, to: :first, allow_nil: true |
There was a problem hiding this comment.
Can there never be different modes on the different tables?
There was a problem hiding this comment.
With the ways we are currently interacting with this collection, no. I can probably enforce that in the initializer if you'd like to be a bit more defensive. The only downside is more work for me 😆 . Adding a guard like that would require dedicated unit tests (we exercise these classes currently via functional tests of the methods that use them).
There was a problem hiding this comment.
I think it's probably worth being defensive if it's not that difficult.
This functionality will allow us to improve the safety of operations that take out locks on multiple tables (e.g. adding / removing foreign keys).
I also discovered a bug in the nested lock acquisition logic, so this PR fixes that and adds more tests.
I feel like it's tradition at this point for me to include too many changes in a PR and for @jcoleman to ask me to break it up into smaller commits 😆 (
I will try to do that tomorrowdone).