Ecto 3.0 is out and stable API

Your Libraries & OS Mentoring Libraries
9

Exactly this. I was going to comment something along the lines, but your comment summarizes my thoughts very well.

This is a sign of maturity, there is no need to provide features for features shake.
Ecto has a mature and stable API. Tested in lots of different applications and built upon the knowledge and lessons learnt of similar systems in other languages and frameworks.

With the improvements on Ecto 3.0 it will only keep getting more and more polished. Great work and congratulations to all the team and those working on the underlying libraries :bowing_man: .

6 Likes
10
11

I really appreciate this direction, Elixir’s core as well as it’s core libs feel very stable, even more so for a relatively new language - that saves a lot of maintenance work. Great job!

4 Likes
12

3 posts were split to a new topic: Your thoughts on advancing the Elixir ecosystem

13

MSSQL is supported in Ecto 2 through tds_ecto or mssql_ecto, where mssql_ecto performs much better in our experience.

There is a however caveat when using parameterized queries, which seems quite undocumented:

This query will fail in both tds_ecto and mssql_ecto
sql = "select * from users where name = $1"

This will work in tds_ecto
sql = "select * from users where name = @1"

This will work in mssql_ecto
sql = "select * from users where name = ?1"

2 Likes
14

José,

I am not certain that I understood your announcement correctly. First you say

Therefore, I am announcing that Ecto has become API stable. I will continue to update it and fix bugs, but no new features are planned nor will be accepted.

but then you say

Alternatively, if you feel like Ecto should go beyond the current stable API and you would like to take Ecto towards new green pastures, that’s definitely an option too. Getting involved with the project maintenance is a good way to get started and learn the ropes.

which seem in contradiction.

Put simply:

Is there any chance for an Ecto 4.0 to happen in the future or not?
Or there will be only Ecto 3.x maintenance versions?

Thanks

15

If somebody else gets involved in the project maintenance, at some point we will be glad to hand off the project and it will be up to them to steer it as they prefer. Unless that happens, there will only be maintenance versions.

4 Likes
16

why not announce you are stepping back from ecto development and interested parties should express interest in continuing development (or ask them to fork and rename if you want to retain control of ecto itself)? pronouncing that ecto will accept no new features makes it seem like you are shutting down development to everyone

17

Forking and/or renaming is always an option because of the license Ecto uses. The core team will maintain Ecto as it is today. The last paragraphs of the post outlined options for people that want to continue to add features to Ecto, what do you think is missing there?

4 Likes
18

I thought the sentence below was pretty clear in that regard:

Personally I love the direction. Ecto does everything that it needs to right now, it doesn’t need to get bloated.

How I understand it is that its feature complete now and if someone needs a specific use case, they can write a plugin, or fork and build on it. And if a new general use case appears in the future that should be added to ecto it will be added after discussion.

1 Like
19

if someone wants to add a new feature to ecto what’s the process? fork? ask to take over maintenance? make a pull request despite jose announcing no new features will be considered?

20

The options are forking or contributing to Ecto to the level where the team thinks you can take ownership of new features or eventually the whole library.

1 Like
21

Isn’t that what the announcement says? Quoting:

The only reason I did not announce I am stepping down from Ecto is because it still has to be maintained until said parties step up. But if you feel like that is not necessary, I am ok with not having to maintain it either. :stuck_out_tongue:

2 Likes
22

Are there actually missing features you‘d like or need? If not, I feel like it‘s not worth having this discussion right now - often times people worry about things that eventually will never happen.

5 Likes
23

Is it finally possible to start / configure multiple repos dynamically? I haven’t seen any mentions of it in the ecto v3 announcements.

The last time I tried to do that, I had to use internal ecto functions which wasn’t particularly convenient.

But for the majority of use-cases ecto probably does do everything that it needs to.

1 Like
24

No, it is not possible yet, as we are collecting feedback from people building stuff using the private APIs - which is not ideal and it will break but at least it is possible. If you can start a new topic here, explaining what you are doing right now, the pros and cons, it can help push the conversation forward. I believe @talentdeficit is interested on this too. This particular item is work that has not been finalized yet.

3 Likes
25

Thanks so much for your long work on this API, José. It’s tremendously appreciated.

7 Likes
26

For anyone using the distillery release task for migrations. With ecto 3 the pool_size needs to be bumped from 1 to 2.

10 Likes
27

Thanks for the tip! Can you give a bit more context as to why this needs to be changed?

28

Ah never mind, I’ve figured it out. From the Ecto 3 Changelog:

Locked migrations

Running migrations will now lock the migrations table, allowing you to concurrently run migrations in a cluster without worrying that two servers will race each other and run migrations twice.

In order for this safer migration mechanism to work, at least two database connections are necessary when migrating. One is used to lock the “schema_migrations” table and the other one to effectively run the migrations.

5 Likes