Ecto-phobia

I haven’t had problems with things like changing column names when using Ecto- a migration and a change to the schema and I’m good to go[^1].

[^1] : As others have pointed out, renaming columns isn’t quite as simple as that, but that’s not a problem Ecto makes any worse.

Cool - yeah, I have been doing more reading this afternoon and I was aware of those things, its probably just more of a personal “issue” of mine

Less about Ecto but database design of a complex systems is a tough task overall. Modifying tables (e.g. adding, renaming, indexing columns) can get messy when you’re in the millions of rows I also always have the anxiety, that little 10% of my mind thinking “what if I had designed this all wrong?”

IMO there’s nothing you can do about it other than to always be ready for change and perhaps consult to a domain expert to make sure you get the terms right (therefore less likely to rename columns; I like to think DB column names are like an API; you’re expected to do some work if it changes).

I think the issue with “ORMs” in general is that they will always be less flexible vs underline store so you always end up with a mix of direct queries and ORM code. When it is up to me I’d rather use DB directly

Database schemas evolve as applications evolve, new tables, new columns, new constraints, drops, renames…

That is normal and to be expected. But think that if the schema changes, you’ll need to edit the code no matter what. Either Ecto, or hard-coded SQL, or stored procedures that depend on it. None of these things auto-update. Renaming a column is not just a SQL statement, it needs maintenance and coordination wherever the column is being used. It may even require multiple deploys if you may have old and new code cooexisting for a moment in a rolling start.

To me, something like Ecto (or AR) is a catalyzer. You know the SQL you need, you could write it by hand. But you instead leverage these tools to have the SQL robustly generated on your behalf, using Elixir code that is more understandable most of the times because of the higher-level API it is expressed in.

Then, occasionally the SQL you need is just too complicated, then you resort to raw SQL.

Embrace Ecto! Yes, it is gonna be alright :).

And just come at the point from a different direction: renaming columns is a good habit to get out of. As your application grows that type of operation becomes one that is difficult to deploy with zero downtime since the application code will All have to change the instant the column name is changed. It is more difficult to roll back in the event of a deployment issue as well.

There is a great ruby gem called strong_migrations/README.md at master · ankane/strong_migrations · GitHub Strong Migrations that tries to protect against these things. I don’t know if there is an Elixir equivalent yet, but that readme is a short read that’s worth looking over regardless of language.

No disagreement here, but the original question seemed to ask if something about Ecto made doing so harder than it otherwise might be. I don’t think Ecto does.

Agreed. Just wanted to address while the topic was there.

It’s a subproduct of relying on ORMs vs RDBMS features if you rely on views or sps your application would not care about changes to to underlying schema

I just want to say, that there is the other side to that. If you learn how to read SQL and write performant SQL, then you can use it anywhere. But if you rely on ORM’s and the like, you have to learn new ORM and it’s DSL’s almost with every new language you use. Beside that if your application get complex enough, no tool like AR, or Ecto will help you, there is a time where you just have to dive into pure SQL. And if you need to write queries by hand in one place, you can IMHO just write it in whole app, this way you can clearly see, and extract to proper “layer” all the DB access stuff.

I’m not against Ecto or any orm just for the sake of it. I actually work mostly with them, and Ecto is really great. But SQL is really neat and very expressive language (compared to, fo example some nosql query languages ) and for me so far it was always way more readable than any ORM or similar tool.

In my job, when sometimes things need to be checked by hand, people tend to open rails console, and use AR to query database. I quickly came to conclusion, that doing raw SQL queries is so much faster and easier.

And in conclusion I find that, when it comes to more complex queries, SQL is actually way more readable than Elixir, or Ruby or any other language I’ve been writing in.