Behaviour for Etcher annotation persistence.

Etcher's <Etcher.layer> component doesn't run any persistence itself — it fires etcher:created / :updated / :deleted events to the consumer's LiveView. Consumers persist via either:

• the bundled Etcher.Storage.Default (writes to the etcher_annotations table — generated by mix etcher.gen.migration)
• their own implementation of this behaviour

Why a behaviour

Etcher is generic; downstream apps often have richer needs than the default schema can express. PhoenixKit, for example, links each annotation to a phoenix_kit_comments discussion thread, so its adapter opens a transaction that creates both rows. Other consumers might fan out to multi-tenant tables, log to an audit trail, etc.

Etcher itself doesn't depend on any specific Repo — the bundled Etcher.Storage.Default reads config :etcher, repo: … at runtime.

Example custom adapter

defmodule MyApp.AnnotationStorage do
  @behaviour Etcher.Storage

  alias MyApp.Repo
  alias MyApp.Annotation

  def create(attrs) do
    %Annotation{}
    |> Annotation.changeset(attrs)
    |> Repo.insert()
  end

  def list_for(target_type, target_uuid) do
    Repo.all(
      from a in Annotation,
      where: a.target_type == ^target_type and a.target_uuid == ^target_uuid
    )
  end

  def update(uuid, attrs) do
    Repo.get(Annotation, uuid)
    |> Annotation.changeset(attrs)
    |> Repo.update()
  end

  def delete(uuid) do
    case Repo.get(Annotation, uuid) do
      nil -> {:error, :not_found}
      row -> Repo.delete(row)
    end
  end
end