-
Notifications
You must be signed in to change notification settings - Fork 899
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
Compatibility problems with optimistic locking / lock_version #163
Comments
@saizai - I know this is a little late, but is there any chance you could provide a failing test to work with? |
I have the same issue just now, has anyone figured this out yet? Keep throwing
whenever I try to undo something with Papertrail. Would be nice to have both functionalities on the same model. |
To quote the rails docs for
|
When using optimistic locking a lock_version integer is saved in the database, if an update is attempted and the lock version is a lower number that the current lock version you will get the |
@justinlyman - Good to know. I don't know if it makes sense to hard code that into PaperTrail since it is technically monkey hacking around the way that db locking is supposed to work, right? If you think it does make sense, feel free to make a pull request. |
using the Rails conventional lock_version, I did:
in version_concern.rb, line 125 just before returning 'model' |
I'm not sure I'd describe that as a workaround. I haven't used optimistic locking personally, but based on the documentation it sounds like you're using it as intended; you want to update a record, so you must increment the lock_version. I'm adding a note to the readme about this. (#550)
I think this would work in a single-threaded app, but without concurrency control would not be sufficient in a multi-threaded app.
I agree. If PaperTrail ever adds a high-level undo function, this is something we'll have to keep in mind. |
Suppose you have a Widget with a lock_version column.
If you try to do
widget.previous_version.save!
, you'll get aActiveRecord::StaleObjectError
.I'm not sure how to override this. Ideally what should happen is that the newly reified object should have the same staleness / lock properties as the original object, so that if
widget
is OK to save thenwidget.previous_version
should be too (since it hasn't changed out from under you).Any ideas for how to implement this?
The text was updated successfully, but these errors were encountered: