Over the last few months, Ecto’s team has been working on some breaking changes to Ecto’s newest version.
In order to explain what changes are going to happen, José Valim is writing a series of blog posts. This is the first one.
The changes happened mostly on three areas:
- Split the Ecto repository apart
- Remove the previously deprecated Ecto datetime types in favor of the Calendar types that ship as part of Elixir
- Update to the latest JSON handling best practices
17 Likes
As one of the people in @michalmuskala’s ears about this change I’m super happy/ecstatic about the ecto/ecto_sql split. It reinforces that split for me it will help get ecto used for many more cases!
12 Likes
As lots of my private projects it’s still top secret, but I’m on way of planning to work on my own version of ecto (after split). It will require one of libraries which I would like to release soon.
3 Likes
I don’t even know some people use ecto for storage other than relational database. I thought that ecto is specific to relational database, no? 
I don’t know any other ORM which has ability to do mapping to non-relational database.
So Ecto here is just the modelling itself?
While ecto_sql contains migration and mapping between elixir code and sql?
2 Likes
Ecto is also useful for mapping/validating user input into internal data structures. It’s not only useful if there’s actually a database at the end.
6 Likes
A typical example of using Ecto without a database would be processing a user-filled form, casting it into a struct and validating its contents.
5 Likes
There has been quite a bit of discussion on splitting Ecto in the past too 
2 Likes
This also talks about using ecto differently at the user input ↔ elixir edge vs. elixir ↔ database.
5 Likes
I thought about it as well.
What @OvermindDL1 said, sounds good.
I kinda wonder that such separation would be great for doing changeset validations on separate module.
In that validation module, we just use the validation library.
Decouple it with the model itself.
That way, I can unit-test the validation module easily.
But I don’t know if these validations will be used elsewhere other than the model themselves.
Btw, I almost confuse you with @LostKobrakai, your profile pictures look similar. 
2 Likes
Haha yes they are quite similar - tho he is the better looking one 
3 Likes
This is a very good news. And maybe I find the courage to not be lazy and find some fellows to develop a ecto_cypher as the Neo4j-fanboy that I am (and because of the open cypher project) 
1 Like
How does one actually end up with a struct after validation and casting? Doesn’t ecto just keep everything in the changes map?
Without the Repo.insert I’m not sure how to get a struct back with the validated changes applied…
you can use Ecto.Changeset.apply_changes/1 to get a struct back from a Changeset
3 Likes
I only mention it because its somewhat new function (I think added in Ecto v2.2), besides apply_changes/1 there’s an apply_action/2 too.
4 Likes
that’s good to hear… I remember working with a changeset and not even attempting to insert it in the db (cause I knew it was invalid from validations with APIs) and wondering why errors didn’t show up… turned out the standard helpers or what not would only show them if an action was present iirc. So I wrote this “dirty” feeling helper which set the action and people debated if what I was doing was right.
I feel vindicated somehow 
2 Likes
This looks like the correct method over apply_changes as it only applies if the changeset is valid. Thanks!
1 Like
I was under the impression that changesets were going to be in ecto_sql and not ecto. I feel like José mentioned at some point that the structure of changesets was so tied to a database it didn’t make sense to break it out. Did that change?
You can see the answer (and rationale) in the issues tracker discussion: https://github.com/elixir-ecto/ecto/issues/2558
2 Likes
I feel like this split was done in the wrong direction. We all know ecto is a database access toolkit and now the database parts of it are not in the ecto repo / package. But main readme documentation and basic information for newcomers is there.
I understand this may have been easier (to split out database stuff and move it to ecto_sql) but after separating the code, I feel like the database access package should have stayed at ecto and the rest should be moved to ecto_core or something similar.
Excuse my bikeshedding 
It’s just we’ll all have to switch and the few people who use ecto without the database won’t. And I’m still not sure where soft documentation (guides) will be.
The switch is literally 1LOC change, which you would likely have to change anyway to get a version bump.
After all of the effort to keep breaking changes to a minimum… reading this is disheartening at best. 
2 Likes
