opened
nikoristar
username_0
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
Migrations > Nested folders support
issue
created
seppevs
username_1
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.
comment
created
nikoristar
username_0
Yes, but 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..
to be honest history is nice, but if people move between projects/leave company/new arrive they can forget to return deleted migrations... 

Another case , which is more realistic, 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.
comment
created
SailingYYC
username_2
I concur with @username_0, 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).
comment