Hello.
I have a Parent Absinthe & Ecto schemas and there’s an embedded child object associated to it (1:1, so the fully inflated object is basically a union of the underlying tables, but it’s not implemented literally that way become some parents may have several fields of Child type, e.g. left_child, 'right_child). I didn't want the Absinthe client to manipulate children directly, so we have a graphQL mutation such as updateParentthat takesparent_idanddataarguments, and withindatayou can provide fields ofParentobject as well as fields ofleft_childorright_child`, e.g.
mutation {
updateParent(id: , data: { name: “new name”, left_child: { diagram: “{ some: json }”, right_child: nil, lock_version: <current_parent_lock_version>}}) {
id, name, left_child {id, diagram}, right_child {id, diagram}
}
We have standard optimistic lock on parent and child:
def changeset(parent, attrs \\ %{}) do
parent
|> cast(attrs, @cast_attrs)
|> validate_required(@rqrd_attrs)
|> update_children(attrs)
|> optimistic_lock(:lock_version)
end
Here’s the usecase I am having a problem with.
If my mutation arguments don’t contain any updates for the parent object the changset is empty and parent.lock_version won’t get incremented. Also, in order to perform updates on fields of Child type, they need to be preloaded:
parent = Repo.preload(parent, [:left_child, :right_child])
which loads their current lock_version values, so there would almost never be a failed optimistic lock because any update of child would have the most current lock_version.
How can I share the optimistic lock of parent with the children, so that if a child is updated the lock_version on the parent is incremented even if parent is not updated? I don’t want to expose children’s lock_version to the client - I want all updates to go through parent.
Semantically, it’s as if children were just fields on the parent, in which case it would work like normal optimistic lock on the parent, but it’s not desirable because children have lots of fields and I don’t want them on the parent table as columns. But this is basically an entity mapped into a union of tables, sometimes parent union-ed with dependent table more than once (as in case of left_child and right_child). I hope that makes sense…
