AO3-6639 Output current DB schema

[brianjaustin]

Pull Request Checklist

• Have you read "How to write the perfect pull request"?
• Have you read the contributing guidelines?
• Have you added tests for any changed functionality?
• Have you added the Jira issue number
  as the first thing in your pull request title (e.g. AO3-1234 Fix thing)
• Do you have fewer than 5 pull requests already open? If not, please wait
  until they are reviewed and merged before creating new pull requests.

Issue

https://otwarchive.atlassian.net/browse/AO3-6639

Purpose

• Output the latest DB schema (based on a Docker setup)
  • This should make new environment bootstrapping a bit quicker
  • Since Rails upgrades change schema formats, we will have a record of things now before Rails 7
• Change the schema output process to update schema.rb when a new migration runs; this will make it so PRs with migrations update by default, saving us work later (we update the structure SQL separately, and that will stay manual as MySQL formats may change to not match real prod)

Credit

Brian Austin (they/he)

[brianjaustin]

(This isn't quite tests, but that's the closest label.)

[Bilka2]

Things I noticed:
Some tables lost the ENGINE=InnoDB option and new tables don't have it. MariaDB defaults to innodb so that seems fine.
The limit option on text columns was converted to size. size is specific to the mysql adapter/schema (and doesnt show up in the docs). Since that's the adapter that's getting used, that also seems fine.

Based on https://github.com/otwcode/otwarchive/wiki/Migrations#why-not-dumping-from-development-environments it may be better to run this in production, not in a local docker setup.

[brianjaustin]

Based on https://github.com/otwcode/otwarchive/wiki/Migrations#why-not-dumping-from-development-environments it may be better to run this in production, not in a local docker setup.

I pulled the schema from a prod DB and it's almost the same as the one from Docker (compare the last 2 commits to see the few differences).

In terms of updating the schema on migrate with Docker, I think it's a tradeoff between 100% exact match against prod and staying more up-to-date. Since we never recreated the prod database from schema.rb, but often do so for Docker, I'm more inclined towards auto-updating the schema and accepting a few slight differences from prod (we can and have dumped the exact structure as SQL elsewhere)

[Bilka2]

Agreed to the reasoning for keeping the Docker schema, good to see that there are no major differences.

Regarding the config, the docs suggest setting dump_schema_after_migration to false in production (and likely also staging).

[brianjaustin]

(I've added the SQL dump too per conversation with @Bilka2 elsewhere; I'd recommend skimming it at most since the diff is a bit larger.)

[Bilka2]

I looked over the SQL dump and it looks consistent with the rb dump and good in general 👍