Damn, Ash sounds more tempting every time I hear of it. Must find an excuse to use it!
3 Likes
People in here who are skeptical of automatic migrations would do well to spend some time in Django. It’s extremely nice and accelerates development by a lot. Especially for new projects or dynamic environments where you aren’t sure exactly yet what the end result should look like.
1 Like
It is really strange to me when so many people will find some reason to disagree with a pretty obvious suggestion/enhancement.
I don’t know if people just like to talk/disagree or if they have trouble coming admitting their library of choice isn’t already perfect.
1 Like
I agree automatically generated migrations via inspecting the diff between last-known table state and current one can be valuable, but have in mind that Ecto schemas don’t directly map to tables in Ecto; people can and have chosen to have different lens on the same table. So that makes this approach untenable. Ecto is not an ORM, it’s a Data Mapper.
4 Likes
Absolutely agree.
For the uninitiated it might seem like a downside, however after working with ORMs from languages like java, the rigidity and magic they provide is their downfall, and it doesn’t take long for that to happen in a project.
At the end of the day if you never used a feature, it’s hard to convince of its usefulness. Go to any developer that never heard of fault tolerance and tell them that this is superior to what they have wrote for years.
1 Like
Well… sure. But that doesn’t mean a semi-automatic tool can’t be built. The Django community discussed this over many years back and forth. Then I wrote an outline of how the UI should work for such a tool and the discussion stopped, and then after a while the tool materialized 
A semi-automatic tool could ask if the model field that is new should be added in a migration. It could ask for other meta-data as needed. I’m not saying it should cover all use cases, but it should be able to cover the easy 99%. Which is how it works in Django migrations.
Also, in Django the migration file is created automatically but it’s not immediately applied. You can look at it, and modify it freely before that. Sometimes the tool doesn’t do the right thing and you have to edit it. But the 99% case is that I just write “./manage.py makemigrations” and in a fraction of a second I get the migration I need.
3 Likes
I do have multiple schemas (in different contexts) mapping to the same table. I guess it would not work in that case?
1 Like
Why not? If you add a column to any of those schemas and the table doesn’t have it, it could automatically create a migration to add it to the table right?
I guess yes…
Coming from Rails, I don’t see this as a required feature.
For reference, how many migrations you are running per day as this kind of functionality is critical for you?
Ecto is probably one of the most used library for production applications in elixir world, so if that feature was of critical value, either a third-party library or ecto itself would have added that option already.
I don’t disagree, I think it could be an interesting experiment in new tooling. It’s just that for one reason or another – I make no claims about knowing that reason – it hasn’t been made yet. Feel free, I’m sure people would try it.
For reference, how many migrations you are running per day as this kind of functionality is critical for you?
Some days zero of course. But some days many. Sometimes I migrate and reset the db from a backup because it turns out the idea I was trying wasn’t a good idea. I have 614 migrations in my work project, and I’ve worked on that solo for ~3 years. That’s roughly 663 working days if my math is correct, so very nearly 1 per day sustained for 3 years.
so if that feature was of critical value, either a third-party library or ecto itself would have added that option already.
I don’t think that’s correct. Humans lived for hundreds of thousands of years before inventing farming. That doesn’t mean farming is a bad idea.
From what I know the migrations system in Django is quite unique and everyone in the Django world loves it and are horrified that other systems don’t have it. They have trouble understanding how you can live without it. And yet such a great system has come into existence roughly once in many decades since databases were invented.
The discussion in here sound quite similar to the one where people argued against the Django migration system before it was built. And yet when the system appeared the community phase shifted extremely quickly to having trouble imaging life without it.
You can even read the discussion: SchemaEvolution – Django Many people suggested doing exactly what Ecto has with manual migration files. Fortunately I saw a simpler way and wrote it up (And even more fortunate someone put in the hard work to build it!)
OK, this discussions is starting to become worshiping, as @dimitarvp mentioned any addition to the ecosystem is not only welcome but encouraged.
Then that is perfect, instead of idolizing your work, maybe you could bring this joy tool to this ecosystem! People here would gladly assist you with internals on how ecto works and potential limitations that you might hit.
PS: I would highly suggest to also read about reading spring boot migrations and the ORM from .net, as those had similar features from way before tools in programming languages were meant to be tokens to brag about to other people.
I didn’t really do much honestly. The hard work was getting the basic system working, and Ecto already has that basic plumbing.
I come back to looking at Elixir a few times a year, but I never pull the trigger to write a hobby project in it, partly because of this missing feature, but mostly the investment in learning a new language. I just would hate it if Elixir+Ecto doesn’t have all the nice things Django has. That’s not how we move the software world forward. We should copy all nice things from other frameworks. I only wish it was possible for the Python ecosystem to copy the BEAM but that’s obviously quite out of the picture 
Then sadly you are missing the bigger picture. I would strongly recommend to build a real-world application in elixir or at least invest good 3 months of effort, it will open a new entire world for you, but be warned, once you get a taste for the ecosystem you will most probably will never want to go back to python 
.
Once again, give ecto a fair try. I had the same opinion when I started out with ecto, however only after using it for a year I understood the beauty of the approach it took, in production scenarios having the flexibility ecto has over any other classical ORMs is “productivity” on another level.
You also don’t move the software world by staying in the comfort zone. To move it forward you need to see the bigger picture. For example Elixir is great not because the syntax is copied from ruby, but because it is a mix of erlang, ruby and lisp on top of a great VM.
I guess this shines some light on how these shiny features never outweigh core critical features. Django might have the most unimaginable features conceived, however as long as it runs on python, that has a stone age concurrency model, the features are not as impactful as you might think.
3 Likes
Multiple things can be true at once.
-
generating migrations from some representation of your schemas can save time and help enforce best practices. We have one for Ash and it provides tangible value to our users. Some users prefer not to use it, some users couldn’t live without it.
-
but its not important enough of a feature not to choose to use Elixir and/or Phoenix. Ecto lacking this feature is not an indicator of a “general lack of features” across the Elixir ecosystem. There are some aspects and conveniences found in other languages and framework that Elixir/Phoenix or Elixir/Ash don’t have, but the flip side is even more true in my experience. And in many cases, the things that we do have are things that are comically difficult to accomplish in other languages and ecosystems. The migration generator is one example of a convenience that, without it, folks are generally fine.
7 Likes
Agreed. I know I’m stuck in a local maxima. 
Python does have some advantages though. Most notably the enormous library ecosystem.
1 Like
Absolutely agree! At the same time arguments provided in format: “this is one of the best feature that every ecosystem should have” without any kinds of examples backing it is not very helpful.
In another light someone might come and say that not having classes and inheritance is also a critical feature missing from the ecosystem, they might be right from their perspective and their use-cases, but it doesn’t mean that the correct course of action is to add classes to elixir.
Indeed, this and lack of elixir jobs are the biggest bottlenecks this ecosystem has. Taking in consideration the AI hype now and the fact that elixir has livebook, nx, axon and bumblebee, I think the adoption might increase dramatically in the next years and this in theory should solve the libraries problem, as for some reason developers love to reinvent bicycles in the languages they use .
1 Like
The flipside can also be true: people want to point out minor features of their frameworks to play them up as something incredible.
I’d be interested to see a workflow here to understand these massive gains. I’m usually adding one or two columns at a time through process of TDD. I push a lot of logic to the db so I always care exactly how the db represents things, so I would always be checking these. Can Django infer things like partial indices? If so, that would be actually be something and have my full attention. But I certainly can’t be bothered to try out Django just to see this feature for myself. I really dislike writing Python.
I would likely use this feature if it were available but, but copying a couple of lines and hitting . a bunch in Vim isn’t painful enough for me to be an advocate for it.
2 Likes
You have to declare partial indexes on the model, but then you run makemigrations+migrate and it’s applied.
