doesntmattr / mongodb-migrations Goto Github PK

I think that the migrations_script_directory config and the related executeScript(Database $db, $file) method add little value for the extra overhead.

https://github.com/doesntmattr/mongodb-migrations/blob/master/src/AntiMattr/MongoDB/Migrations/Version.php#L261

It would be easy enough for anyone to load the javascript file and run it directly against $db in their own migration if they wanted it.

I would like to make this feature deprecated to be removed in 3.0.

Hello,

I'm updating an application, and I need to update doesntmattr/mongodb-migrations, doesntmattr/mongodb-migrations-bundle, and other MongoDB related packages.

But unfortunately, I can not find UPGRADE.md file, or any other documentation to help this migration.

Do you have any pointers ? 🙏🏼

Thanks

I think it would be great if --show-versions printed the description from the migration.

See related ticket for the Bundle: doesntmattr/mongodb-migrations-bundle#10

It would be good if we had a build that run the unit tests with the minimum requirements.

I think I've seen this in the doctrine/mongodb-odm (?) travis build.

It would be good to upgrade phpunit to 6.0 or 7.0 (preferred)

Currently we depend on the antimattr/test-case but we could probably bring that code into our tests and drop that dependency. Then make the necessary updates.

Scrutinizer gives Configuration class an F:
https://scrutinizer-ci.com/g/doesntmattr/mongodb-migrations/code-structure/master/class/AntiMattr%5CMongoDB%5CMigrations%5CConfiguration%5CConfiguration

It is not hard to see why.

There is this confusing inheritance model:

       Configuration (concrete)
            |
            v
   AbstractFileConfiguration (abstract)
      |                |
      v                v
XmlConfiguration YamlConfiguration  (concrete)

And there are a bunch of mutators on Configuration just so that the bundle can overwrite settings here: https://github.com/doesntmattr/mongodb-migrations-bundle/blob/master/Command/CommandHelper.php#L38

Suggest we apply:

• Composition over inheritance;
• Apply the single responsibility pattern;
• Immutable configuration;

These are just ideas. Would need to look more into how the Configuration class is used.

Note that improvements here could also improve the Doctrine migrations library https://github.com/doctrine/migrations because it follows the same structure: https://scrutinizer-ci.com/g/doctrine/migrations/code-structure/master/class/Doctrine%5CDBAL%5CMigrations%5CConfiguration%5CConfiguration

@caciobanu mentions here:
https://github.com/antimattr/mongodb-migrations/issues/16#issuecomment-242758294

To create a new repo rather than clone.

@caciobanu do you mean to remove the fork reference? Is there some other advantage?

e.g.
Sonarqube https://www.sonarqube.org/
Sensiolabs Insight https://insight.sensiolabs.com/docs/github/analyze-a-php-library-on-github.html
Scrutinizer https://scrutinizer-ci.com/
CodeClimate https://docs.codeclimate.com/docs/open-source-free

The AbstractMigration::$db attribute here:
https://github.com/doesntmattr/mongodb-migrations/blob/master/src/AntiMattr/MongoDB/Migrations/AbstractMigration.php#L43
is never set in the constructor.

Instead, the AbstractMigration::$connection is incorrectly overriden with a Database here:
https://github.com/doesntmattr/mongodb-migrations/blob/master/src/AntiMattr/MongoDB/Migrations/AbstractMigration.php#L55

I imagine no one uses these because you get a Database with up() and down(). You can get the Connection from the Database.

I think we should just remove these attributes from AbstractMigration.

When we push into a PR travis runs a build for the Push and for the PR even though the content is the same.

Add Travis or alternative (?)

It should:

• load dependencies
• run unit tests

@trq
@caciobanu

I've created 1.1.0-beta on packagist and brought it into our composer.json to see if all is well. It seems so at the moment.

1.1.0-beta contains all the open PRs from the other package plus php-cs-fixer changes.

https://packagist.org/packages/doesntmattr/mongodb-migrations

Suggested updates:

1. Minimum php is 7.1 - update travis yml
2. Drop antimattr/test dependency
3. Update phpunit to 7 (see #20)
4. Switch to [ ] array syntax
5. MongoDB Adapter:
   1. Firstly, add "alcaeus/mongo-php-adapter" as a dependency
   2. Secondly, look at removing usage of mongo-php-adapter by using MongoDB base classes
6. Set up code quality tool #23

Complete the changes for the bundle too https://github.com/doesntmattr/mongodb-migrations-bundle

Using MongoDB server version newer than 4.2 causes the tool to stop working. Error appears when JavaScript is used to carry on the migrations.

The cause is the removed MongoDB eval command used by the tool.

Stack trace:

Migration 20210104082001 failed during Execution. Error no such command: '$eval'
In DatabaseCommand.php line 101:
no such command: '$eval'

@redthor is there any change this would be fixed or alternative way to execute javascript via the tool?

I'm not sure whether this is the appropriate use case but I use execute (on very rare occasions) to run migrations that are re-runnable. The issue is that we get this error:

 [MongoDuplicateKeyException]                                                                                                                   
  db.acme.com:27017: E11000 duplicate key error collection: acme.migration_versions index: version dup key: { : "20161117052356" }  

I suggest that we either:

• do not bother attempting to insert a migration version (probably not wise)
• do an upsert instead to update the date
• create a version like 20161117052356-1 (sounds complicated)

I think the upsert option may be the best?

Error (edited to remove our specific app file paths etc):

/usr/bin/php app/console mongodb:migrations:status -v --env=it --dm=domain_document_manager --show-versions

 == Configuration

    >> Name:                                MongoDB Migrations
    >> Database Driver:                     MongoDB
    >> Database Name:                       domain
    >> Configuration Source:                manually configured
    >> Version Collection Name:             migration_versions
    >> Migrations Namespace:                App\Infrastructure\InfrastructureBundle\Migrations\MongoDB
    >> Migrations Directory:                <PATH>Migrations/MongoDB
    >> Current Version:                     2018-04-11 00:20:11 (20180411002011)
    >> Latest Version:                      2018-04-11 00:20:11 (20180411002011)
    >> Executed Migrations:                 12
    >> Executed Unavailable Migrations:     4
    >> Available Migrations:                12
    >> New Migrations:                      0

 == Available Migration Versions


In StatusCommand.php line 129:
                                                             
  [Symfony\Component\Debug\Exception\ContextErrorException]  
  Notice: A non well formed numeric value encountered        
                                                             

Exception trace:
 AntiMattr\MongoDB\Migrations\Tools\Console\Command\StatusCommand->execute() at PATH/vendor/doesntmattr/mongodb-migrations-bundle/Command/MigrationsStatusCommand.php:41
 AntiMattr\Bundle\MongoDBMigrationsBundle\Command\MigrationsStatusCommand->execute() at PATH/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at PATH/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:964
 Symfony\Component\Console\Application->doRunCommand() at PATH/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:86
 Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at PATH/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:248
 Symfony\Component\Console\Application->doRun() at PATH/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:74
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at PATH/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:148
 Symfony\Component\Console\Application->run() at PATH/app/console:27

mongodb:migrations:status [--show-versions] [--configuration [CONFIGURATION]] [--db-configuration [DB-CONFIGURATION]] [--dm [DM]] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command>

This was produced from master. This is probably due to the change introduced in #30 as we've changed it from \MongoTimestamp to MongoDB\BSON\UTCDateTime. Just needs something to normalise the date as the db may have a mix of these two types.

Alternatively we should ship something to migrate all the dates?

Hopefully \MongoTimestamp is actually MongoDB\BSON\Timestamp. Probably should check that otherwise we will need a migration to ensure no one using v2.0 is still requiring the mongodb-php-adapter.

Hi guys..

I've seen you recently adapted to \MongoDB\* classes in many places, switching from the \Doctrine\* classes (like for accessing Connections and Collections and so on).

This is perfectly fine - but currently only available in the master branch.

Is there any idea/roadmap when this will be (if still work is needed) finalized and tagged? We would like to have a stable tag that use the new \MongoDB\* classes.

Thanks so much

When running --show-versions I get:

  [Symfony\Component\Debug\Exception\ContextErrorException]  
  Notice: Undefined variable: executedUnavailableMigrations  

I think Configuration needs to pass it back to StatusCommand somehow.