db migrate should also run db structure dump

[timriley]

No description provided.

[jodosha]

@timriley From this placeholder, it isn't easy to guess.

If you're looking for hanami db migrate, which automatically dumps db/schema.sql, I'm not for it.

We had hanami db apply, which had the purpose of:

1. Run pending migrations
2. Refresh a db/schema.sql file
3. Delete all the migrations

https://guides.hanamirb.org/v1.3/command-line/database/#apply

[timriley]

Ah, I wasn't aware of db apply in 1.x, thanks for pointing that out to me.

However, I'd still be keen to learn why you're not in favour of dumping the schema after migrating.

From my perspective, there's a few reasons for it:

• It keeps db/structure.sql up to date after every db migrate is run. This makes db/structure.sql valuable as a file that always depicts an up to date database structure. I regularly refer to this file in the course of everyday work, and having it lag behind the actual latest version would be a problem.
• It means that db structure load in development can be used at any time, because the db/structure.sql is kept up to date.
• It allows old migrations to be safely be removed — via any means, not just a special command, so even plain old rm works — at any point after they've applied to all the necessary deployments.
• It's consistent with Rails, and therefore familiar to many of our users. Hanami is already different in so many ways, if we can find and keep a few points of familiarity like this, they can all do a little bit to reduce the feeling of strangeness and increase our new users' feelings of comfort. IMO there's nothing particularly wrong with how Rails' db:migrate works (with it doing the structure dump automatically), so it feels like we may as well keep it.

Personally, if we didn't offer this "dump on migrate"-style behaviour, I'd need to somehow find a way to ensure "db migrate" and "db structure dump" are always run together in my projects, either via an extra script/migrate, linting tools in CI, or something that patches the behaviour in-place in the hanami CLI. I'd obviously prefer not to do any of those 😅

Lastly, I'd actually be concerned to run that db apply command in its current form, because I don't think I'd ever want to delete all migrations. I'd probably want to be selective in the point from which I do the deletions, based on my own understanding of my application and the state of its various deployments. Deleting all feels too harsh and inflexible.

Keen to hear your thoughts!

[parndt]

This definitely caught me by surprise! I thought I'd misconfigured ROM. For now I made it work like this for my app:

class MigrateAndStructureDump < Hanami::CLI::Commands::App::DB::Migrate
  def call(**options)
    super
    Hanami::CLI::Commands::App::DB::Structure::Dump.new.call
  end
end

Hanami::CLI.tap do |cli|
  cli.register "db migrate", MigrateAndStructureDump

[olivierlacan]

I'd agree that dumping or applying the latest migration to update the schema is a good convention to carry over.

I've found myself drudging into the depths of manually dumping Postgres DDLs in projects that don't offer this type of tooling just so I can quickly get a CI environment loaded, or even to set up a blank slate local test db on team development machines when there are years of (yet-to-be rolled up) migrations to go through just to get a dev environment going.

It seems reasonable to make this an opt-out behavior however, since some folks may have no use for the schema?