Right now there are 2 systems (in each module) ensuring that most recent SQL schema is used by the database:
upgrades.phpfiles, that define release versions of each module and what SQL/PHP code needs to be executed during upgrade
project_upgrades.sqlfile, that have sequential (starting from 1) revisions, where each can contain set of SQLs that needs to be executed
project_upgrades.sql file was defined to allow easy incremental updates without a need to run full module upgrade process. This works pretty good when project based on In-Portal is developed and it's not actually ever released.
However, when we're developing In-Portal itself the SQLs are added to the
upgrades.sql and there is no way of tracking to which internal revision it belongs. Because of this after updating In-Portal installation developer either needs to do full re-install of In-Portal or figure out which SQLs needs to be executed and execute them. Same goes for PHP code, that needs to be executed during upgrade.
I propose, that we:
upgrades.sqlfile (then it will have both incremental revisions and release tags)
- allow PHP code to be executed along with each revision in 3 modes (like it does for release versions): before SQL, after SQL, after language pack
- make Deploy button in charge for whole upgrade process (won't be needed to go to Admin Console and select which modules to upgrade and which not)
- the module upgrade from installation wizard will basically hit Deploy button internally
Here is the final format for the
This way each version will consist of set of revisions. Tricky moment is what should we display as module version in module list however. We can display latest version, but that won't expose information about fact, that some of sub-revisions in that version are not yet executed.
- Alternative approach of splitting single
upgrades.sqlinto several files based on version (one file per version) is discussed in [install] Changing way, how upgrade scripts are stored [5.3.0-B1], but I believe this is bad idea considering that we might have 300 revisions at some point and having all of them as files could be problematic.
- [deployment] Using file-per-revision for Deployment Script