Ecto version-controlled data and form - what is the recommended practice for this?

I have been working on a platform where we have to manage some kind of documents and particularly the versioning. I have the rest of the platform up and running with most of the stuff done but here come the central piece: The document management.

For the POC I did something simple for testing in the lights of:

  schema "documents" do
    field :title, :string
    field :body, :string
    belongs_to :organisation, MyApp.Organisations.Organisation

    timestamps(type: :utc_datetime)
  end

It works well - we validated our idea and are now going to the next step.

But now comes the part where I will need to manage versions and state of the documents.

I came up with something like this:

  schema "documents" do
    # more fields
    field :draft_version, :integer
    field :published_version, :integer
    belongs_to :organisation, MyApp.Organisations.Organisation

    timestamps(type: :utc_datetime)
  end

  schema "document_versions" do
    field :title, :string
    field :body, :string
    field :version, :integer

    # this has_one doesn't work and I think I will change it to belongs_to
    has_one :author, MyApp.Accounts.User
    belongs_to :document, MyApp.Documents.Document

    timestamps(type: :utc_datetime)
  end

It looks OK I guess. We will not have millions of documents and with index on the version with version/document I guess that will work.

But now comes the time to have the forms. A “new” document will basically create a document and the first version. “Edit” a document will create a new version (loading the content from the previous version) for a document.

I have been struggling with that side. I am using live_view from the frontend and I started to look for embedded forms to get that going.
That’s where I stumbled upon the embedded_schemas… I was wondering if this would be actually a fit for my use-case. I am still relatively new in Elixir/Phoenix/Ecto and learning around that. What would be the recommendation for a case like this?

I’d suggest ignoring forms for a bit. Make the underlying business logic work (e.g. using tests) and only then figure out how to can make LV provide the necessary data to your core APIs and to which part and how those values need to be provided by the user with a form vs directly from e.g. the LV state.

Not really an answer to your question, but have you considered using a library for the versioning, such as GitHub - izelnakri/paper_trail: Track and record all the changes in your database with Ecto. Revert back to anytime in history. ?

That’s how I started and actually the second version I mention is actually what I have with some tests and it works just fine. Where I am more struggling it is how to make the LV and that’s also when I got to find the embedded_schemas and wondered if that would be useful there…

Thanks for the tip. I actually looked for it but didn’t find anything. It seems that this could simply do the job but it also seems that it hasn’t been updated in 2 years. I am wondering if this could become an issue on the long run…

I’m using it quite happily (well a forked repo, since the maintainer seems slow on merges but has been occasionally responsive: a few things by mayel · Pull Request #224 · izelnakri/paper_trail · GitHub )