You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issues with two Repositories that use LockingAndVersioningRepository after locking 1 in each the delete of the lock can be called from either repo
#2153
Open
rhhaley opened this issue
Oct 11, 2024
· 3 comments
I have two Repositories that extend LockingAndVersioningRepository after locking 1 in each repo with the same @id (which is the entity_id) in a test then delete of the lock of either it deletes the lock from the lock table.
A little background:
We have two types with content and our goal is to be able to version both.
Products
Attachments
Steps to reproduce the behavior:
Create two entities with @id that are autoincrementing Integers.
Create one of each in a fresh database. This should show that each id is 1.
Lock one.
Check the lock table you should see entity_id will equal 1.
Lock the other but notice the lock owner doesn't get set on the second entity (not seeing any error).
You'll see there is only one lock in the locks table and with the entity_id = 1.
Call unlock on either repository and you'll see the lock in the lock table be deleted.
Is there a way to make the entity_id to use a custom property.
We are an ex Documentum shop and want to us a similar id structure for document based entities.
Let me know if more info is needed.
The text was updated successfully, but these errors were encountered:
rhhaley
changed the title
Issues with two Repositories that use LockingAndVersioningRepository after locking 1 in each the delete of the lock will can be called from either repo
Issues with two Repositories that use LockingAndVersioningRepository after locking 1 in each the delete of the lock can be called from either repo
Oct 11, 2024
Thanks @rhhaley for raising this. You are quite right. I had not considered the case where an application has two (or more) entities with content and I can imagine the existing implementation exhibits the behavior you describe. I think we can make the lock table use a composite key, perhaps. Or construct a "composite" key in the LockingAndVersioningRepository. Where the composite key includes the type name. Let me look into it a little bit.
I didn't quite catch the last comment about using a custom_property though. Can you explain that a little bit more?
So with regards to custom_property I was thinking along the lines of instead of id from the entity you could something like the id we geneate but I think using contentId (which is a guid) and entity_id in the locks table is a String could work?
Otherwise a compound index that uses type, class, or entity name and entity_id would work just as well.
We are using 3.1.4
I have two Repositories that extend LockingAndVersioningRepository after locking 1 in each repo with the same @id (which is the entity_id) in a test then delete of the lock of either it deletes the lock from the lock table.
A little background:
We have two types with content and our goal is to be able to version both.
Steps to reproduce the behavior:
Is there a way to make the entity_id to use a custom property.
We are an ex Documentum shop and want to us a similar id structure for document based entities.
Let me know if more info is needed.
The text was updated successfully, but these errors were encountered: