Migrations vs PackageActions

[Rusty Swayne]

For UaaS, I've heard one should use Migrations instead of package actions for package installs.  This makes sense and I think should be pretty straight forward to get going - but what about uninstalls?

I have not done the deep dive into the Umbraco core, so forgive me if this is not an issue, but does Umbraco issue a downgrade migration to Version 0.0.0 or something when a package is meant to be uninstalled?

[Shannon Deminick]

We haven't yet fully covered how Migrations will work for packages. Currently there is nothing in the core that is ensuring migrations for packages are executed. This will be coming post 7.3 and should make things much nicer for package developers and will also allow for us to use Nuget to install packages and their data... since we can run migrations on boot. Again, this hasn't been fully spec'd out yet but it will be soon(ish).

It's not just UaaS, this is for all Umbraco. Until that time however you'll need to use package actions, or if you need to install custom data after install you can do that if you launch a custom UI after package install (i.e. this is what articulate does).

As for uninstall, it's a good question! Perhaps something like issuing a downgrade to version 0.0.0 might work... We'll have to see once implementation has begun though.

[Rusty Swayne]

Thanks Shannon, that really helps especially with the time frame.  I'll watch 7.3.0 more closely.  

I am presently managing Merchello migrations in Merchello's boot manager.  When you say 

Currently, there is nothing in the core that is ensuring migrations for packages are executed.

 are you inferring that there will be some sort of migration register which would allow the package developer to implicitly qualify the package migration  or is the concept to simply check the version of the dll from which the Migration sets were resolved?  Or is this question premature - and I should just hurry up and wait =) ?

[Shannon Deminick]

Yes, in 7.3 there is a new table to track migrations. Currently this is for the Core but it already has the columns in place to support packages. We use this in 7.3+ to ensure that the installer is executed on all of your environments even if you deploy the web.config from dev -> staging with the new version in the web.config. We detect that the migrations haven't actually been executed and the installer will still run.

In the future, we will use a similar concept for packages. On startup (or somewhere/sometime/yet to bet officially determined) we'll check if there are migrations that exist for a package that haven't been executed based on what is stored in the db and execute them. We've only begun discussing how this will be implemented yet as there's a couple of options: Show an installer screen when package migrations are detected, similar to the core one since there are packages that need to be updated. Or attempt to do it silently on first run and block all requests until it's done and if there's an error then we'll need to display that somehow to retry (this of course could have other strange ramifications). 

[Rusty Swayne]

Appreciate the heads up on the new table.  It sounds like a better solution than the AppSetting value I am currently using.  Also, I really like the concept that the installer screen will be shown for package migrations.  I had a stab at trying to get that going when Merchello was updating, but things started to get pretty messy and got pretty clunky rather quickly.  

I'll keep my eye on 7.3

On Thu, Jul 23, 2015 at 6:41 AM, Shannon Deminick <sdem...@gmail.com> wrote:

Yes, in 7.3 there is a new table to track migrations. Currently this is for the Core but it already has the columns in place to support packages. We use this in 7.3+ to ensure that the installer is executed on all of your environments even if you deploy the web.config from dev -> staging with the new version in the web.config. We detect that the migrations haven't actually been executed and the installer will still run.

In the future, we will use a similar concept for packages. On startup (or somewhere/sometime/yet to bet officially determined) we'll check if there are migrations that exist for a package that haven't been executed based on what is stored in the db and execute them. We've only begun discussing how this will be implemented yet as there's a couple of options: Show an installer screen when package migrations are detected, similar to the core one since there are packages that need to be updated. Or attempt to do it silently on first run and block all requests until it's done and if there's an error then we'll need to display that somehow to retry (this of course could have other strange ramifications). 

--

Rusty Swayne

Merchello

http://merchello.com

@rustyswayne