1stSolo

Share `lockVersion` between parent and child?

I have a parent-table and a child-table; they are 1:1 - the “child” could have been a set of fields on the parent but it was better to decompose that into two separate tables to better handle some special cases (e.g. some “parents” have two children in the “child” tables).
I originally had lock_version on both parent and child tables, but can I instead have lock_version only on the parent?
The GraphQL API we have allows to update the child only through parent, e.g.
updateParent(parentId:<id>, data: %{child: %{description: "new value"}}, but in this case when the arguments are passed into Ecto changset it doesn’t actually increment lock_version on the parent because none of the parent’s fields changed. If I could somehow detect a change of the child and trigger 'lock_version increment on the parent then I would not need the child to have its own lock_version. Anyone done this before?
The only downside here is that if “child” is modified by any other means other than the above API endpoint, e.g. by batch or trigger then optimistic lock won’t fail because Ecto is not aware of the changes in the db until it fetches the data.
But the basic idea in the setup here is that parent and child only happen to be decomposed into 1:1 tables, but they are virtually one table and thus not necessarily need a lock_version (or own timestamps, for that matter) on the child.
Alternatively, one could always set child’s lock_version to the parent’s lock_version when creating the changset for the child?

1 comment

#ecto #absinthe #optimistic_lock #ecto-schema

0 355 1

2024-01-24 20:31:00 UTC

Marked As Solved

1stSolo

I have a solution. Turns out, Changeset.cast_assoc is extremely useful when parent and child are updated together as a single unit as is my use-case. Even though the data is decomposed into two related tables, semantically the dependent/child is operated on as if it were a property of the parent module.
As the result:

Don’t need to have lock_version on the child since parent’s lock_version is updated if cast_assoc detects a change in the child
Requires to preload the assoc for cast_assoc to be able to detect changes
For cast_assoc to behave properly and perform insert/update/delete based on the existing state of the dependent object, id of the child needs to be provided (it can be copied from Parent..id) or else Changeset will raise because the default for :on_replace of the association is :raise.

Example:

defmodule Project do
  use Ecto.Schema
  import Ecto.Changeset
  import Ecto.Query
  ...
  schema "projects" do
    field(:name, :string)
    field(:description, :string)
    field(:version, :string, default: "2.0")
    field(:owner_id, Ecto.UUID)

    has_one(:design, Design, foreign_key: :project_id)

    field :lock_version, :integer, default: 1
    timestamps(type: :utc_datetime)
  end

  def changeset(project, attrs \\ %{}) do
    supplied_design = attrs[:design]
    attrs =
      if not is_nil(supplied_design) and not is_nil(project.design.id) do
        Map.put(attrs, :design, Map.put(supplied_design, :id, project.design.id))
      else
        attrs
      end

    project
    |> cast(attrs, @cast_attrs)
    |> validate_required(@rqrd_attrs)
    |> check_constraint(:name, name: :name_length, message: "Project name \"#{attrs[:name]}\" is too long.")
    |> unique_constraint(:name, name: :project_name_unique, message: "Project name \"#{attrs[:name]}\" must be unique")
    |> validate_text_length(:description)
    |> cast_assoc(:design)
    |> optimistic_lock(:lock_version)
  end
  ...
  def update(%Project{} = project, attrs) do
    Repo.transaction(fn ->
      project
      |> Repo.preload(:design)
      |> changeset(attrs)
      |> Repo.update()
      |> case do
        {:ok, project} -> project
        {:error, error} -> Repo.rollback(error)
      end
    end)
  end

So Project.get(<uuid>) |> Project.update(%{design: %{diagram: "{\"some_json\": \"here\"}"}}) is then all is needed and the lock_version will get incremented with either Project or Design had changes. This allows to update both parent and child with a single optimistic lock field; timestamps, however, will be updated in both tables if child has changes.

Post #1