This project is read-only.

Story around using data migrations during development

Topics: Troubleshooting, Writing modules
Dec 27, 2011 at 9:39 PM

So I'm a bit confused about what the story is about updating modules when the update requires a data migration. For example lets say I create a module with some simple part in it then enable it on my site. Later on I want to add a new field to my part so I put the field on the part and the record and in the migrations file and rebuild. But then when i try to go to the site to do the update that would run the migration code that would allow the module to work correctly I can't because nHibernate complains about how that column in the table doesn't exist and it won't let me into the admin interface to update the module. Now there are a couple ways to fix things such as commenting out the field on the part until I can run the data migration but that's not a viable solution if you are wanting to be deploying the same code into multiple environments. I could also manually disable the module in the database in the Settings_ShellFeatureStateRecord table, unfortunately that appears to be cached somewhere that an IIS reset won't clear which means I have to wait an inordinately long time to get back to work. Is there some better story about doing migrations that I am not aware of?

Jan 3, 2012 at 9:18 PM

Is there any way to update a module without having to go into the admin interface?

Jan 4, 2012 at 12:02 AM

There is the command-line as well, but the latest 1.x version has auto-migrations, so you actually don't have to do anything.

Jan 6, 2012 at 9:59 PM

Ok thanks. I guess we'll need to update then.

Oct 2, 2012 at 12:48 PM

The file App_Data\cache.dat holds cached data from Settings_ShellFeatureStateRecord.  Just delete it to see your changes take effect.