Do you have to run mix ecto.migrate when working with an existing db table?

Can you please expand on this since, as I said, I am not so deep in Ecto to see all the advantages that has

With ecto you can model abstractions in, which donā€™t map 1:1 to whatever table setup you have. You might e.g. want to expose different sets of fields for the same data in different contexts of your domain (multiple schemas <-> one table) or you might have some domain concept, which applies to many tables, which comes handy when doing polymorphic associations using multiple tables e.g. when many things can have comments, ā€¦ (one schema <-> many tables).

Iā€™d suggest reading through the guides of ecto, especially this one: Data mapping and validation ā€” Ecto v3.7.0. I hope this makes it a little clearer that ecto schemas are not ā€œtable objectsā€.

However I donā€™t want to deny the fact that having a (potentially substantial) db existing it can take a while writing the ecto schemas for that. However I also feel thereā€™s benefit in doing that from the perspective of business logic needing to be implemented, rather than mechanically pulling all of that out of the db, void of more concrete domain knowledge.

I think thereā€™s benefit to having the schemas generated 1:1 with the tables and using that as a starting point to venture off into the other complexities Ecto has. It might even be enough to stop there for some people. Even though Ecto doesnā€™t enforce that kind of relationship Iā€™m sure there are people using it that way. Not that it wonā€™t be complex to make, but Iā€™m not skeptical enough yet to think it canā€™t be done well.

I think I have to reinforce what @joey_the_snake is saying

To me a model generator has the only function to avoid rewriting the DB into another syntax even if I get that some cases cannot be translated.

I also get that writing the DB from the ECTO point of view can be a way to validate all the constraints, relationships and part of the business logic that an application has been built upon.

I have still doubts about some of the things @LostKobrakai commented but first I have to dive into the links he suggested before arguing with my experience in DB design

Hope someone will have time to dive into the tool that has been abandoned last year