This project is read-only.

Better processing database migration?

Topics: Core
Jul 17, 2012 at 8:32 PM

I changed the way of processing database migration.

Now it is possible to determine the execution order of migrations, if we created multiple migration classes. It is useful if we create one class migration per one class record, and we need to create eg a foreign key between tables.

Firsty, all Create() actions will be executed, then all UpdateFromX() method in ascending order of parameter X.

What do you think about my pull request ( ) ?

Jul 17, 2012 at 10:57 PM

Thanks for the contribution but I'm against it: it's adding complexity where none is needed. Migrations are already executed in order. There is no need to create multiple migration classes.

Jul 18, 2012 at 5:48 AM

We use the orchard as a framework. On average, the module creates more than 20 tables. If we create 1 migration class per 1 record class is easier to manage the code.  It is more clearly and easier to track changes becouse we create migration class in same file where is class record definition.

Jul 18, 2012 at 8:22 AM

We do something like that, we have on migration class and per 'upgrade from' we call the relevant internal method of records that require an update (we could do all and just check the curVersion, but we prefer to only call the method when a record actually has something new to do)

Method header is this: internal static void UpdateFrom(int curVersion, SchemaBuilder schemaBuilder, IContentDefinitionManager contentDefinitionManager)

Maybe something like that could work for you too? I guess you could even automate it a bit using reflection if wanted.

Jul 18, 2012 at 2:24 PM
Edited Jul 18, 2012 at 2:25 PM


I wanted to share with you our mega super DatamigrationManager :-). We used it in our projects by override standard datamigrationmanager

Jul 18, 2012 at 2:27 PM

Well I always (overstatement ;p) have time to look at your code - throw it at me :P