Oh, well cool then! One thing I wish I had in Ecto that I used to add anyway (thinking it did something) was being able to give nil: false to field. That would actually be awesome to be able to declare indices as well.
Sorry for big reply, they are my specialty.
Nobody here will argue with you against having even better developer experience. My pet theory is that most Elixir devs simply don’t find the value-add as big as to roll up their sleeves. I’ve met some pretty hardcore devs during my still-ongoing Elixir tenure (turning 8 years in April) and they could author pretty much anything they needed – but 99% of the time they said “nah it’s fine, we’ll have this wrapping module with 5 functions and we’re done, no need to over-abstract” and that was that.
Maybe that speaks something of the culture of the community? I wouldn’t go as far as to guess as widely, to me it’s just “it would be cool, yeah, but I am faring just fine without”. Good Elixir devs are very diligent.
…Though I’ll also agree that the computer should do the maximum for us. This is why it’s fairly likely that I’ll move to full-time Golang and Rust work in the next few years. I want types and I want the maximum checks done for me before I run the program and at one point I’ll put my money where my mouth is.
Strange over-fixation on a singular feature. If you did some production Elixir work for 3-6 months you’d see that this little problem is easily drowned out in a sea of other much more serious, issues like proper multi-step migration of schema + data , introducing constraints, tightening NULL leisure, migrating data between API versions, and many others.
Let’s go further: get rid of all framework-specific migration mechanisms. I like EctoSQL’s migrations DSL but I almost wouldn’t notice if it disappeared tomorrow. IMO we the programmers spread our efforts too wide and too thin. It’s time to start converging. Why argue about Elixir vs. Python? Have one good DB migration tool that’s easy to distribute (should likely be written in Golang due to its excellent cross-compilation and distribution story) and let’s all contribute to it, I say. We’re wasting our time by arguing minutia; let’s all start working on TheOneUltimateTool™!
Here are some links with framework-agnostic tools on this topic but not only:
- GitHub - xataio/pgroll: PostgreSQL zero-downtime migrations made easy
- GitHub - bikeshedder/tusker: PostgreSQL migration management tool
- GitHub - fabianlindfors/reshape: An easy-to-use, zero-downtime schema migration tool for Postgres
- GitHub - amacneil/dbmate: 🚀 A lightweight, framework-agnostic database migration tool. (on first glance I look this one the best)
- GitHub - rdagumampan/yuniql: Free and open source schema versioning and database migration made natively with .NET/6. NEW THIS MAY 2022! v1.3.15 released!
Also DashBit wrote about multiple migration directories here: Automatic and manual Ecto migrations - Dashbit Blog (already posted in earlier replies here in this thread).
Never happening, Python is a giant hulking mastodon that’s moving with glacier speed. You guys just got a tool that allows you to turn off the Global Interpreter Lock and even that’s not officially sanctioned IIRC.
In the meantime, OCaml team worked several years to make the language runtime full-multicore-enabled, they achieved it and they are now not far behind the BEAM – they are already working on IO-bound and CPU-bound task pools and they also have actor libraries stepping on OCaml 5.0+ (which is the multicore-enabled version). Just a few more pieces of the puzzle and they’ll have BEAM 2.0. I give them 3 years or so.
Rust’s async language features and runtimes eat a lot of flak – from yours truly included – but the team is relentlessly working on making a bunch of higher-order async constructs possible and they are making steady progress (like working on async traits and lifetime rules relaxation in async context; both are a big deal). Rust’s async capabilities are CRAZY; well-written programs regularly saturate their host’s 10GbE network link and still don’t hit 100% CPU.
Golang has GitHub - sourcegraph/conc: Better structured concurrency for go which definitely removes some of its annoying builtin footguns.
There are likely other examples.
If you want 21st century concurrency / parallelism then you don’t belong in the Python ecosystem – this is how it looks to me from the sidelines.
I understand your risk aversion and lack of motivation to get out of the comfort zone, we all have that, but it’s IMO going to pay off for you to be realistic and either just embrace Python fully with its defects included or, ahem, defect to another programming stack.
Cool. When I retire, I’ll probably work on transpiling Python to other languages and Python will lose its advantage overnight after I am ready. 
And I am VERY much in agreement with @sodapopcan here:
There are some gains, sure. Massive though? Don’t think so.
Introspection and self-reflection skills are really nice to have. Kudos. 
And finally, as @D4no0 said, just build something with Elixir. Make it a goal outside of your work time, like a hobby that’s only going to last a few weeks. There’s no replacement for real production experience.
1 Like
@boxed Just to be clear because I remember once a Django dev thought this: you are aware Ecto does have migrations, correct? It’s not like we’re hand-rolling a schema update feature. You just have to copy paste some stuff. I can see it being super annoying if you’re used to not doing it, but a killer feature that you write off a whole framework for? That’s just odd. It feels like looking for a reason not to like something, especially considering all the other really nice stuff Ecto can do.
The reason Ecto probably doesn’t have is due to the general Ruby inspiration of Elixir. Of course, in Rails it’s actually backward: since models auto-infer all the column data, you only write the migration (which, again, can be generated),
1 Like
I think you guys are putting more emphasis on it than I intended to put.
But I do want to point out that the answer to “how many?” was in fact roughly 1 per day. Every day. For 3 years.
If a tool makes something easier and faster, this changes behavior. It’s not just that it’s more convenient to do what I would have done anyway. Friction causes behavioral changes in the subject.
Ecto’s flexibility in allowing multiple schemas to map to the same table or a single schema to map to a subset of columns in a table is undeniably a significant feature. However, I don’t see this as a “roadblock” to the automatic migrations feature being discussed in this thread.
Introducing an additional “schema” like concept, which we could refer to as a “model”, could serve as a reliable source of truth. This would be an optional feature, utilized by those who prefer the convenience of automatic migrations, and it’s unlikely to cause any harm to the existing features.
However the primary advantage I personally see in this approach is that it can provide a clear understanding of the database structure by simply examining these models, which serve as the basis for generating automatic migrations. The utility of these models could be further enhanced if they could be annotated with optional informative comments. A kind of documentation.
While the resulting system may not be flawless, there’s always the option to manually edit the auto-generated migrations before executing them, as suggested by another participant in this discussion.
On a related note, I have previously used the Django framework. Although its automatic migration feature was not perfect at the time, I appreciated having all the fields of a given table defined in one place for easy reference. Currently, in my Elixir projects, I maintain this information in a LibreOffice Calc file, with each sheet representing a table in the project database.
Without a doubt, I am fond of the idea of incorporating a database modeling tool, possibly even a graphical one, into the Elixir ecosystem. However, I recognize that this will entail a significant amount of work and is not likely a high priority at the moment.
How about mix ecto.dump?
You can add comments to your table columns.
Not sure why this should be limited to Elixir; there are tools out there you can use to build databases interactively, if memory serves.
1 Like
I will eplore this. Thanks for sharing.
Well the issue here is that since there will likely be several migrations files on the same table with the time., I will have to read all of them to grasp the whole model… But I guess the mix ecto.dump thing will come handy here. But I will have to try it to see if it produce a nice result to read through and to understand.
I think I may have miscommunicated my point. I’m not expecting this to be done by the Elixir core team, as I know they have more important tasks. However, I just wanted to say that having this feature wouldn’t hurt. In any case, you can always suggest free tools for Linux to accomplish this. So far, the best tools I’ve found are draw.io for graphical diagrams and LibreOffice Calc for defining tables that describe the database structure. If I could find a free tool that does both at the same time, I wouldn’t turn it down. If I have the time and skills, I might even create an Elixir library for this one day. I’m just putting my idea out there, of course, without demanding anything.
mix ecto.dump is producing a singular SQL file. Is that not good enough?
Additionally, you can generate a graphical representation of your DB via a tool like e.g. GitHub - fuelen/ecto_erd: A mix task for generating Entity Relationship Diagram from Ecto schemas available in your project. by @fuelen.
1 Like
Not typically one to plug my stuff, but folks who were a fan of Django and/or the automatic migration generator might want to look at Ash Framework. We’ve had a migration generator for years, and I’ve been told that Ash bears some similarities to Django 
EDIT: well, not typically one to plug my stuff unprompted 
.
5 Likes
