[whatl3y]

While this is fair and I don't disagree that changing a column name or possibly other schema changes using an ORM and it's subsequent migration scripts is potentially going to be a faster exercise than without one, changing a column name (or any schema change for that matter) in a database in my experience is rare. If you choose to use an ORM for reasons like it might (emphasis on might) be a bit faster and easier to change a column name than without one instead of for other more meaningful people or efficiency-oriented reasons of the day-to-day developer workflow is probably a poor approach.

Keep in mind I've installed and used an ORM in projects where the ORM is used only for migrations, but not used in application code and this is absolutely a fine reason to use one imo. But adopting an ORM for migration purposes and forcing or using in application code simply because it's installed isn't necessarily a good approach.

[scrollaway]

Like I said, it's one example.

ORMs are to SQL what static types are to programming languages. The conversation we just had was me giving you one example of the benefit of static types, which happens to showcase a huge weakness in dynamic typing:

- How painful is it to rename a class attribute?

=> It's a long search & replace exercise which results in a less-than-certain outcome.

The obvious take from this isn't that "renaming class attributes is rare".

[LunaSea]

This is a very simplistic view of the situation.

ORMs have very basic support of current SQL standards and database specific features.

This means that using an ORM reduces the power of the database choice you made.

Also things like arbitrary SQL support imply you have to manually creat return value typings.

Having to leave the nice ORM wrapper functions for arbitrary SQL means you lose all the ORM niceties like soft deleted or updated_at fields

Overall I see very little use for ORMs.