Allow many assemblies to contribute IMigrations in the same migrations run

[JulianRooze]

See: #463 for the original issue that I created.

In short: not all of our migrations are in the same assembly. This is deliberate as our application is very modular in nature and a module is able to define its own (very specific to its need) tables and other database objects, so migrations are present in several assemblies. Currently, it's only possible to do this through iterating through all your migration assemblies and creating a separate runner for each one, which doesn't necessarily run the migrations in the correct order.

I've made a change that preserves current functionality (you can still pass in a single Assembly instance to the runner) but adds the ability to also provide a IAssemblyCollection instance. The current overloads that accept a Assembly parameter default to creating a implementation of IAssemblyCollection, namely SingleAssembly.

I've tried to keep breaking changes to a minimum, but to preserve sensical naming I've had to rename properties that are part of the public API to "Assemblies" instead of "Assembly".

[nfplee]

I've just had a chance to test this. I have a modular application and this seemed like a good idea. Each assembly/module has a class which implements IVersionTableMetaData. This allows me to have a separate set of migrations per assembly/module and the versions are managed per assembly in a separate version table (ideally this would be within the same table but you would need to store the assembly which run the migration and remove the unique constraint on the version).

However if I have a migration within each assembly with the same version number then it throws an error.

I know I can get around this by looping over each assembly and running the migrations per assembly but it's quite slow and also the transaction is managed per assembly so if one statement fails in an assembly then it doesn't prevent the remaining assemblies from trying to commit their changes.

[tommarien]

@JulianRooze How does this work, it's just a runner change for programmatic access ?

[JulianRooze]

@tommarien Yes, basically, that's how the change is exposed to the outside. We use a console application as our migration runner that scans all loaded assemblies for IMigration implementations and feeds those assemblies to the standard MigrationRunner, which now also accepts a IAssemblyCollection.

Internally, places that previously accepted an Assembly instance now accept a IAssemblyCollection which is then used to aggregate all migrations from all those assemblies into a single feed. The only two things that were ever accessed on Assembly were GetExportedTypes (to find the implementations of IMigration) and GetManifestResourceNames (for accessing assembly embedded SQL scripts) which have been exposed on the IAssemblyCollection as well.

[tommarien]

@JulianRooze i would consider merging it in if the code was 100% backwards compatible

What i mean is that for instance the msbuild runner should have both options still open : old style 1 assembly and new multiple assemblies for instance

Any chance you can create a branch from our source and reincorperate the changes in a backwards compatible way ?

[JulianRooze]

The MsBuild changes were a contribution by @esakal. I'll take a look if I can make that backwards compatible.

How do you suggest I approach keeping the naming backwards compatible while keeping them sensical? I did a lot of renaming in 28d02b8 because naming something typed IAssemblyCollection with a singular name like "Assembly" doesn't make a lot of sense, so I pluralized those to "Assemblies".

I suppose I could expose both a property of type Assembly called "Assembly" and a property of type IAssemblyCollection called "Assemblies". Would that be okay? And how would that Assembly property behave when the migration uses multiple assemblies? Throw an exception, return the first assembly?

[tommarien]

@JulianRooze i just quickly checked the change by esekal, it already looks backward compatible, i guess all should be fine

[JulianRooze]

Okay, thanks for the check. Let me know if you need me to make any changes to make this mergeable.

[tommarien]

@JulianRooze Thanks Julian, seems to run fine ;)