Migrations > Nested folders support

[nikoristar]

Hello, I have checked source, but couldn't find option/approach to support folders inside "migrations dir". e.g migrations -> release 1.0 -> mig1, mig2... -> release 1.1 -> mig3, mig4... etc...

Would it be possible to add support for such approach? (Or maybe there is a alternative approach for large amount of migrations/keeping history?)

I assume that depth can be configurable with default 0/1, doubt that it ever will be higher than 2-3...

Thank you

[seppevs]

You can also just remove the migration files each time you do a big release (and all migrations are applied in all environments)? If you have put your migrate-mongo project under source control, then you are still able to find your migration files in the git history if you ever have the need for that.

[nikoristar]

Hello, thank you for taking look into this request,

Yes we could use history, but:

1: When you add new environment, you need to return all migrations to source control, migrate, then remove again.. this is not often case but can happen.. and but if people move between projects/leave company/new arrive they can forget to return deleted migrations... (new environment can be added temporarily for performance tests, or by client request etc..)

2: Developers can have isolated environment for development including own DB (e.g started via docker) and if new developer comes to project or data there became messy after some time, DB can be deleted and recreated from scratch.

[SailingYYC]

I concur with @nikoristar, I found this project as we are looking for something like flyway but for MongoDB. The ability to bring up net-new databases, bring in the schema, populate data, perform migrations is a highly beneficial use case. Even if you look at CI automated testing of migrations, populate a DB with a known version of test data, apply migrations, validate, reverse migrations, validate it meets the original form.

We are contemplating the need for multiple sub-directories, more so for controlling who can update which set of migrations, but the problem as it presents itself is that all migrations, regardless of sub-dir, would need to be sorted into time-code sequence. We are contemplating is this would present too much of a disconnect for developers when debugging.

In adhering to this type of pattern, is migration metadata stored in a collection? Is the SHA hash of each migration file stored in that table and used to validate that migrations that have been applied do not differ from the migrations now being presented (as this could represent a deviation, dev building new migrations based on an incorrectly altered historical migration).

[seppevs]

Will not add nested folder support. I want to keep migrate-mongo as simple as possible, to avoid unnecessary complexity in both the code and usage of this tool. Closing this.