When you install a new version of DNN or a module, the installer performs a number of operations, including SQL updates, upgrade code, file cleanup, etc. When you are performing a "skip upgrade", these operations are performed sequentially by type of operation rather than performing each type within each version being upgraded. Here's an example:
I assume this order of operations is used to minimize the application restarts, but it can be problematic.
As an example, suppose I have version 1 installed, and want to install version 3, but version 3 removes a table used by version 2.
When the installer runs, these operations would occur:
Now, assume there is upgrade code in version 2 that uses the table to do something. But version 3 removes the table. In that case, the upgrade code for version 2 will fail, because the SQL update for version 3 has already run, and removed the table.
In the Forums module, we've made a lot of structural updates, and so far we've been able to work around this behavior, but I envision a time where we might break an upgrade, say someone upgrading from version 6 to version 9. We really don't want to create a multi-version upgrade path requirement. We also don't want to recreate the entire SQL landscape with every version, but rather, leverage the current SQL installer to bump from version to version.
Is there any interest in the community for changing the installer behavior, perhaps as an option in the manifest to order the operations by version?
These Forums are dedicated to the discussion of DNN Platform.
For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:
Awesome! Simply post in the forums using the link below and we'll get you started.