I have 2 entities: parent and child.
The parent entity have a life cycle so it transits from one status to another a.k.a ‘open’ or ‘discard’.
When it transits (it is a transactionnal action with multi) any child can’t be created.
I check before create child that the parent is open but i need that check to be on the commit of the creation transaction because the parent can change while the child is beeing created. I don’t want the parent to be blocked because of children. The parent blocks the childs but the children don’t block the parent.
I thought on locking but it is not suited to my need because it solves concurrency and here the case is more a blocking in only one direction.
How can i solve this problem?
Do you think using prepare_change is suffisant and safe?
I hope i expressed clearly.
Thank you all
If your parent record can change at any time then there really is not much you can do.
Not sure I understood you well but you can use Ecto.Multi and pair that with DB triggers that disallow insertion of children if the parent is “locked”. I had cases in my career when we had such requirements and usually limiting things in the DB itself is the way to go.
and the changeset of child has a validation that the parent is open, in a prepare_change functions.
I am just afraid the abandon_parent occurs while the create_child, just after the Multi.insert so the validation will not help.
I don’t want to block the abandon action of the parent.
The parent has one owner. But child may be created by anyone.
If you are really serious about this, then you can implement some database level change to forbid changes to the child while the parent is locked (maybe an exclusive lock on the parent, advisory locks would work well too) but that can seriously gimp your performance
Another way to do it would be to funnel all mutations to the child through the same thing that mutates the parent (persistent process, works well with one host and less well as you add more) - but you can handle all this in the app
Triggers might or might not work as you can have the transaction that changes the parent and the transaction that changes the child start concurrently. Assuming that this is Postgres, the result might be surprising
This was my first thought. Specifying a for share lock while checking that the parent is open should guarantee consistent behaviour while allowing some concurrency (depending on whether parent is otherwise updated in the transaction). Explicit locking can be done in Ecto with lock.
Thanks a lot!
Locking while checking the parent is open seems to be the solution.
I think i will go for optimistic_lock that will ensure the parent didn’t change its status while the create_child transaction occurs.