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










Showing Posts 1 to 5- Show Best Posts
- Show All Posts (oldest first)
- Show All Posts (newest first)
LostKobrakai
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.
mayel
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. · GitHub ?
pierrefourgeaud
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…
pierrefourgeaud
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…
mayel
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 )