Cherry pick of row locking logic from vamosa's fork plus extention to set_default_left_and_right case (ANS issue #70)
Cherry pick of row locking logic from vamosa's fork plus extention t…
…o set_default_left_and_right case (ANS issue #70)
@MarkusQ this makes 13 specs fail when I merge it... for you, too?
I didn't see any test failures, but something may have changed incompatibly in the master since then. I'll take a look at it in the morning (it's late here) and report back.
Resolve conflict between rails scope & sql ordering in race condition…
It was conflicting with the "default" order on the scope (which, contrary to what some of the rails docs imply) can't be overridden. I've fixed it by allowing the nested_set_scope to take an ordering (which defaults to the old value) and passing in the ordering rather than trying to change it after the scope has been created.
Allow options to be overridable and converted the lock code to ARel. (#…
@MarkusQ thanks for doing that, I've merged your code and made a little tweak to it in 75cfe90. Can you confirm that my tweak is valid? I basically just converted the code to ARel.
None of the tests failed when I did this, but then I'm not sure there are any tests exactly covering this locking feature -- how can we go about having tests for this?
That looks reasonable; not modifying the user's option hash was a good catch.
I don't know of any good way to test this sort of locking code with ruby tools that isn't far more pain than gain. We could scatter magic checkpoints throughout the code and force various interleavings, but that would make just running the test an act of heroism and leave us only slightly more confident--assuming we didn't introduce new bugs in the process.
I'd say the test suit should cover functionality, and treat the locking issues as living at a meta level, along with things like load testing, etc. Testing them should be an external use issue, not something to try to do from the inside.