[RandyCupic]

Adds Doctrine migrations for the bundle's database tables.

• migrations/doctrine.yaml with its own version table, ngrm_migration_versions; doctrine/doctrine-migrations-bundle is now required
• Version030000 creates ngrm_remote_resource and ngrm_remote_resource_location, identical to what doctrine:schema:update generates; down() drops them
• Migration class names follow the package version they ship in
• INSTALL, UPGRADE and CHANGELOG updated; INSTALL shows how to run the migrations from Composer post-update-cmd

Run with:

php bin/console doctrine:migrations:migrate --configuration=vendor/netgen/remote-media-bundle/migrations/doctrine.yaml

Existing installs already have the tables, so mark the initial migration as executed once (see UPGRADE.md):

php bin/console doctrine:migrations:sync-metadata-storage --configuration=vendor/netgen/remote-media-bundle/migrations/doctrine.yaml
php bin/console doctrine:migrations:version 'Netgen\RemoteMedia\Migrations\Doctrine\Version030000' --add --configuration=vendor/netgen/remote-media-bundle/migrations/doctrine.yaml

[emodric]

You said that "Existing installs already have the tables, so the initial migration fails there."

Does that mean that DB changes specified in 3.1.0, 3.1.1 and 3.1.2 migrations are completely new?

[emodric]

I see that this setup is taken from Netgen Layouts, so let me explain the versioning logic there:

class names for migrations strictly follow the tags of the layouts/core package. e.g. Version030102 would be added ONLY in 3.1.2 of netgen/layouts-core and not in 3.0.0, like it's here. That is, migration versions DO NOT HAVE their own versioning scheme/timeline, they entirely depend on package version.

If NGRM e.g. does not have any DB changes in 3.1, 3.2 or 3.3, but has in 3.4.0, next migration version after 030000 would be 030400. That way you explicitly see in which version of package a certain migration was added.

Now here, as far as I understood, some changes are old (030000) and some are new (030100, 030101, 030102). If that is the case, I would propose to only add 030000 now, tag it with 3.0.0, and imediatelly after, in patch 3.0.1, add a new Version030001 migration that aggregates existing 030100, 030101, 030102.

That way, you will have it in sync, and current schema separate from new stuff, allowing for marking 030000 version as already executed.

[emodric]

This can be documented that it can be added in Composer post-update scripts.

[emodric]

Also, you should provide down methods for rolling back the migration versions.

[RandyCupic]

@emodric Please check the PR again, everything should be fixed now.