Auto migrate the version table

[goetas]

This is a proposal on how to migrate the v2 versions table to v3 versions.

The thing that worries me here is that we do not ask the user if we should alter the table or not.

Does it make sense to have a separate command for it?

[goetas]

ping @alcaeus

[alcaeus]

The thing that worries me here is that we do not ask the user if we should alter the table or not.

I'm not sure if a separate command on its own would be the solution.

For most commands, we can ask an interactive question if we see that there's a diff to the migrations table. If the users approves, we update their table and then continue the migration normally. If they don't want to upgrade, we abort the migration.

For commands that are run non-interactively, e.g. as part of a deployment, we obviously can't get any consent, so I believe the best course of action would be to tell people to run a separate command to update manually, then restart the migration process.

[OskarStark]

Does it make sense to have a separate command for it?

I would say yes 👍

[goetas]

There are the following options:

1. Do silently the conversion on the migrations_versions table

• pro: simple and convenient, no extra actions are needed from the user
• con: implicitly writing to the database (a write command will be issued on a simple migration:status command as example

2. Have a separate migration command to update the migrations_versions, if another command is issued and the table is not up to date, return an error

• pro: simple to implement
• con: now we introduce a new step to be performed. Probably will annoy who uses automated processes in CI/CD

3. Add a --allow-metadata-update parameter to all the commands. Apply option N.1 if the param is not specified. Return an error if the parameter is not specified and the table is not up to date. Still offer a command for manually migrating the table (meas offer N2 too)

• pro: no unexpected behaviors that the user is not aware of (everything is explicit)
• con: a bit more stuff to implement
• mixed pro/cons: new --allow-metadata-update to be added on CI/CD pipelines

I'm personally for option n.3. Any other idea?

[alcaeus]

I would agree that method 3 is the safest choice, as it will require people to acknowledge the change and decide whether they want to individually approve every version table migration or allow it to be updated automatically

[goetas]

• added checks in "read" commands that detect if the storage is not up to date
• added command to update metadata storage
• auto-migrating metadata storage when running migrations
• added tests for related updates of schema and data

[goetas]

Moving to doctrine#878