Orchard Hungary is an archive

This site is now an archive. We'll keep it so the content is accessible, but we won't update it anymore. However, we frequently publish Orchard-related news on our other site Orchard Dojo, so be sure to check that out instead. And if you're interested in news about our Orchard development company, Lombiq, check out our website.

Migrating content part data to the infoset - upgrading your module to be Orchard 1.8 compatible part 2.

Tags: Orchard 1.8, Orchard, upgrade, development

So you've already upgraded your Orchard module to be compatible with the upcoming 1.8 version. Since your parts now use the infoset to store data you also removed some records. But how to migrate data from the old database tables, that are otherwise not needed and should be removed? Let's see.

First of all: you'll only need to worry about migrating data from the records to the infoset if you remove records: this is commonly the case with site settings and other content parts that shouldn't be queried on. If your content part records remain then there is no need to do an explicit migration (see Bertrand's blogpost for details).

If you have a large number of rows to migrate then use the technique employed in Orchard's built-in Upgrade module: it basically migrates content items in batches of 50 in a controller action, and you can start this migration with the press of a button. If a batch is done it reloads the page and processes the next batch. You should use this technique or something similar to process many items, because you have to do the work in batches not to be in the danger of a timeout. If you have a small number of records (and thus, rows in the database) or even only one with site settings then you can use the below pattern.

For a small number of records or site settings the following solution is simpler and requires minimal user interaction:

  1. Create a new feature in your module for the upgrade, e.g. ModuleName.Upgrade. The feature should depend on the built-in Upgrade module.
  2. Add a new migration class under that feature. This will handle the upgrade.
  3. In the migration class do the upgrade through the Upgrade module's UpgradeService, then finally remove the now obsolete table that previously was backing your record.

Now what your users have to do is simply enable the upgrade feature of your module, let the data migration run, then disable the feature. Due to the nature of migrations it can be run only once, what is desired.

You can also remove most of the import/export code you may have as data stored in the infoset is automatically imported and exported.

Quite simple to implement. For an example on how to do the third step take a look at the Combinator module's upgrade migrations class. The delegate in ExecuteReader() runs for each row in the table: so although this example is about migrating site settings, where there is only one row, it will work equally well for multiple rows.

Happy upgrading!

No Comments