4 ms·

Good tools explain the tradeoffs they make and provide escape hatches for when you need to sink down to the lower level (since all abstractions are leaky in pra

Good tools explain the tradeoffs they make and provide escape hatches for when you need to sink down to the lower level (since all abstractions are leaky in practice). Use the escape hatches appropriately. Also - not turning on logging for your ORM and looking at what it generates or using an n+1 detector, linter, etc is the fault of the dev team, not the 'incompetent PM'. Also the example declarative migration doesn't really feel declarative to me. Seems pretty... procedural? To me declarative is "describe the final state desired and I will generate/execute the diff". In practice I find migrations need backfill + biz logic sprinkled in. > Migrations first, not schema first. Similarly I don't think this works in the real world either. Please consider the poor junior dev who checks out the code base for the first time and tries to run migrations and then seed data. The best practice has, imo, long been to load a schema file which represents what the db should be at the head of a branch and then load up your seeds. Migrations are to catch your team and live environments up. They occasionally get nuked from the codebase as everyone reconciles their environment. > And the problem with portability is it comes at the cost of specificity. I don’t want a database access tool, I want a Postgres access tool. I want it to expose Postgres’ power user features as first-class features, I don't know about Python based ORMs but ActiveRecord does this.

raman162 3y ago
Yes I thought ActiveRecord's ORM addressed a lot of the pain the OP mentioned with traditional ORM's. ActiveRecord is also the first and only ORM I've used extensively and I've been a fan of it. Prior to that, I used to stick to raw sql, most apps were smaller but even then it felt like a drain to write repetitive sql to find, insert and update records.
llimllib 3y ago
> They occasionally get nuked from the codebase as everyone reconciles their environment. Yes, and also migrations really have to be expressed as code, and you don't want to have to maintain your old functions forever because they are tied to a migration; alternately you don't want to always have to be refactoring your migrations, which is a dangerous and thankless task
- jeremyjh 3y ago
  Or just avoid all use of application functions in your database migrations, and you never have to worry about either problem.
cryptonector 3y ago
> > Migrations first, not schema first. > ... TFA says this in the context of ORMs. But in the context of not-ORMs I think migration-first == schema-first: just use `CREATE .. IF NOT EXISTS`, `ALTER ..`, etc. to set up the schema from the get-got, and you'll think about and cover migrations as you go. The problem with ORMs is that they hide the SQL bits and so if they don't get this right then you'll suffer.
RadiozRadioz 3y ago
> The best practice has, imo, long been to load a schema file which represents what the db should be at the head of a branch and then load up your seeds. Migrations are to catch your team and live environments up. I'm delighted to read this - I tried this method as an experiment in one of my projects, and I really liked it, but I had never seen anyone else do it. Good to hear a confirmation that it's worked elsewhere too. I'd like to add that it's also advantageous when spinning up DBs in Docker; you can mount your "head" schema files right into initdb.d and have them execute when the container runs.

raman162 3y ago

Yes I thought ActiveRecord's ORM addressed a lot of the pain the OP mentioned with traditional ORM's. ActiveRecord is also the first and only ORM I've used extensively and I've been a fan of it. Prior to that, I used to stick to raw sql, most apps were smaller but even then it felt like a drain to write repetitive sql to find, insert and update records.

llimllib 3y ago

> They occasionally get nuked from the codebase as everyone reconciles their environment. Yes, and also migrations really have to be expressed as code, and you don't want to have to maintain your old functions forever because they are tied to a migration; alternately you don't want to always have to be refactoring your migrations, which is a dangerous and thankless task

jeremyjh 3y ago
Or just avoid all use of application functions in your database migrations, and you never have to worry about either problem.

cryptonector 3y ago

> > Migrations first, not schema first. > ... TFA says this in the context of ORMs. But in the context of not-ORMs I think migration-first == schema-first: just use `CREATE .. IF NOT EXISTS`, `ALTER ..`, etc. to set up the schema from the get-got, and you'll think about and cover migrations as you go. The problem with ORMs is that they hide the SQL bits and so if they don't get this right then you'll suffer.

RadiozRadioz 3y ago

> The best practice has, imo, long been to load a schema file which represents what the db should be at the head of a branch and then load up your seeds. Migrations are to catch your team and live environments up. I'm delighted to read this - I tried this method as an experiment in one of my projects, and I really liked it, but I had never seen anyone else do it. Good to hear a confirmation that it's worked elsewhere too. I'd like to add that it's also advantageous when spinning up DBs in Docker; you can mount your "head" schema files right into initdb.d and have them execute when the container runs.