Laetitia
Hi everybody,
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
.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
dimitarvp
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.Multiand 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.Laetitia
Hello,
thank for your response.
I already use Multi.
What do you mean?
Here is a snippet:
and the changeset of child has a validation that the parent is open, in a
prepare_changefunctions.I am just afraid the
abandon_parentoccurs while thecreate_child, just after theMulti.insertso 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.
evadne
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
sasajuric
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.
Laetitia
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.