I think there's a misconception here. Ecto itself does not need to be tied to your database.
I actually use Ecto a lot to validate data and enforce a schema, without even mentioning the database.
There's even an open issue at the Ecto repository that will split the ecto package into ecto and ecto_sql, with the former enhancing the schema and changes management of the first one with database access functionality. So in order to use Ecto the way it is today, you will need to include both packages, and if you don't need the database access functionality you can just ditch the second package. All of this in the next version (3.0).
So no, I don't think Ecto is a bad choice for linking the domains, as it is positioning itself as a data validation library that can be enhanced with database access. :)
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.
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. :)
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.
I think there's a misconception here. Ecto itself does not need to be tied to your database.
I actually use Ecto a lot to validate data and enforce a schema, without even mentioning the database.
There's even an open issue at the Ecto repository that will split the ecto package into ecto and ecto_sql, with the former enhancing the schema and changes management of the first one with database access functionality. So in order to use Ecto the way it is today, you will need to include both packages, and if you don't need the database access functionality you can just ditch the second package. All of this in the next version (3.0).
So no, I don't think Ecto is a bad choice for linking the domains, as it is positioning itself as a data validation library that can be enhanced with database access. :)
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 anEcto.Multifor committing. However, if there's an error I lose some of the context when translating back from theEcto.Multifrom 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. :)