Let’s see if I understand.
I’m going to answer my own question, let’s see if I’m getting it right.
Question
I have done some changes to both the code and the database structure in the dev branch.
How do I merge the code from dev to prod and change the production database to match the structure of the development database?
Answer
These are two independent steps.
For the code, you merge dev to prod the way you normally do, regardless of any changes in the database.
For the database, you use a tool that does the following two operations:
- database → schema - takes a database in input and creates the schema that defines it
- schema → database - takes a schema in input and changes a database to match it
You can use this tool to get the schema from the development database and use it to change the production database.
Have you ever noticed a “Resolve…” button under a “Schema Mismatch” warning at the bottom of a database configuration? That button gives access to this tool.
The schema is the middleman between the two operations. The first operation takes one database in input and generates a schema, the second one takes a schema and modifies a database so it matches the schema.
The tool has always access to all the databases in the app. Databases can be linked to environments and environments are linked to branches, but the tool always sees all the databases, regardless of which branch is currently checked out.
On the other hand, the tool has only access to one schema, the one stored in the yaml file of the active branch. You can use the tool to get the schema from the development database, store it in the current yaml file, then use the tool again to get the schema from the yaml file and use it to change the production database. It doesn’t matter which branch is active, the yaml of the active branch is used as a clipboard to temporarily store the schema. The schema is stored in the yaml file permanently and its changes will be included in the next merge, but you can think of it as a temporary clipboard.
The IDE always checks whether the current schema is consistent with each database and shows a warning for every database that is not consistent with it. This can be misleading, because the schema stored in the prod branch may be consistent with the production database, but if you check out the dev branch, the IDE will tell you that the schema of the production database doesn’t match, and, worse, invite you to change it.
The schema is used only during the schema → database operation described above, so, with the exception of when you are changing your database, you can ignore those schema mismatch warnings.
Assuming that this answer is correct, thank you @jshaffstall and @p.colbert for patiently holding my hand and shedding some light on my darkness.
It would have been clearer if the command that changes a database was together with other database management commands, instead of being disguised as a “resolve” button that resolves a temporary issue. I think it would belong here:
If the app needs the schema for other reasons (like generating the tables the first time it runs on the open source server as mentioned by @jshaffstall), then the schema should be automatically stored in the branch a database is linked to (via the environment) and kept updated every time the database changes. If the database is changed by another app, then the IDE should update the schema when the app is loaded and the change is detected. It could show a warning to the user, but I don’t see the point.