Skip to content
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

Add Optimistic Locking #286

Closed
jcoyne opened this issue Oct 26, 2017 · 3 comments
Closed

Add Optimistic Locking #286

jcoyne opened this issue Oct 26, 2017 · 3 comments
Assignees

Comments

@jcoyne
Copy link
Member

jcoyne commented Oct 26, 2017

In Hyrax/ActiveFedora, we can use the Etag to do optimistic locking. Does Valkyrie have a mechanism for doing this?

See:
https://github.com/samvera/hyrax/blob/master/app/actors/hyrax/actors/optimistic_lock_validator.rb

@tpendragon
Copy link
Collaborator

No. I've been thinking about this lately and trying to decide what the correct mechanism for this would be. Something like AR where there's a special lock_key property which when defined will do optimistic locking?

@tpendragon tpendragon changed the title Optimistic locking? Add Optimistic Locking Mar 14, 2018
@tpendragon
Copy link
Collaborator

tpendragon commented Mar 14, 2018

Proposed Success Criteria:

class Resource < Valkyrie::Resource
  attribute :title
  attribute :lock_key # Reserved attribute for when you want to enable optimistic locking
end

resource_1 = persister.save(resource: Resource.new)
resource_1.lock_key # => "unique1" # Set by the persister.
resource_1.title = ["test"]
resource_2 = persister.save(resource: resource_1)
resource_2.lock_key # => "unique2" # Set by the persister.
resource_1.title = ["test2"]
persister.save(resource: resource_1) # => Valkyrie::Persistence::StaleObjectError # Raised because resource_1.lock_key does not match the lock_key in the database (resource_2.lock_key)

@tpendragon
Copy link
Collaborator

Alternative API:

class Resource < Valkyrie::Resource
  optimistic_locking
  attribute :title
end

@tpendragon tpendragon added ready and removed Groomed labels Jul 18, 2018
hackartisan added a commit that referenced this issue Jul 30, 2018
connected to #286
connected to #453

Co-authored-by: Adam Wead <[email protected]>
Co-authored-by: Michael Tribone <[email protected]>
hackartisan added a commit that referenced this issue Jul 30, 2018
connected to #286
connected to #453

Co-authored-by: Adam Wead <[email protected]>
Co-authored-by: Michael Tribone <[email protected]>
@hackartisan hackartisan self-assigned this Jul 30, 2018
hackartisan added a commit that referenced this issue Jul 30, 2018
connected to #286
connected to #453

Co-authored-by: Adam Wead <[email protected]>
Co-authored-by: Michael Tribone <[email protected]>
hackartisan added a commit that referenced this issue Jul 30, 2018
connected to #286
connected to #453

Co-authored-by: Adam Wead <[email protected]>
Co-authored-by: Michael Tribone <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants