That's really interesting, I hadn't seen that issue yet.
Do you use an intermediate layer of Ecto changesets to map between contexts? Using embedded schema and other such patterns has lead to some headaches for me. I posted a question on the Elixir Forum that I never got a reply to (sadly, I can't link to it because they appear to be down right now) around this very problem.
I'd love to hear how you approach the problem of decoupling from the database while still using Ecto! It sounds like Ecto is moving in an interesting direction.
Well, I usually don't :D
But I use Ecto to normalize some parameters and returns that have nothing to do with the database (like returns from external APIs). This gives me confidence that I could move my persistence layer without that much change in my domain's boundaries.
I'm interested to hear how using embedded schemas backfired with you, though. :)
Elixir Forum is back up, so I can link you directly to the issue.
Basically, I'm presenting a schema that embeds two other schemas to use in a single form within Phoenix.HTML.Form.form_for/4. This schema is then translated into an Ecto.Multi for committing. However, if there's an error I lose some of the context when translating back from the Ecto.Multi from the schema-of-schemas.
This is all to work around what I see as a deficiency in the impl for Ecto.Changeset in Phoenix.HTML.FormData.form_for_errors/1. It doesn't play nicely with the error state for my construct.
There is likely a better way to do what I'm trying to do, but I'm still wrapping my head around this. :)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.