Child pages
  • [deployment] Incorporate "upgrades.sql" into "project_upgrades.sql" [5.2.1-RC1]
Skip to end of metadata
Go to start of metadata

Right now there are 2 systems (in each module) ensuring that most recent SQL schema is used by the database:

  • upgrades.sql and upgrades.php files, that define release versions of each module and what SQL/PHP code needs to be executed during upgrade
  • project_upgrades.sql file, that have sequential (starting from 1) revisions, where each can contain set of SQLs that needs to be executed

The 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:

  1. merge project_upgrades.sql file into upgrades.sql file (then it will have both incremental revisions and release tags)
  2. 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
  3. 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)
  4. the module upgrade from installation wizard will basically hit Deploy button internally

Here is the final format for the upgrades.sql:

# ===== v 4.0.1 =====
# r1: INP-1254 - Module language isn't used during upgrade
UPDATE Language SET IsPrimary = 1;
UPDATE CustomField SET ItemType = 'text';
# r2: INP-1124 - Something else
# ===== v 4.0.2 =====

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.

Related Discussions

Related Tasks

INP-1420 - Getting issue details... STATUS


  1. I like the idea.

    Here what I think - in modules section we can show major In-Portal version and Revisions that where executed already - as a list separated by comma as we have it in our DB for custom module right now.

    1. If we have 200 revisions per version should show 200 numbers next to version. That what's I'm unsure about.

      1. We can have some logic there when we focus on missing (non-deployed) revisions in the list (grid) and have entire list of executed and not in detailed mode (edit mode) of the module.

        We really need to know the total count of missing revision to make some kind of judgment.


        1. Instead of displaying all of revisions it makes sense to group them into ranges instead. So if we have "1,2,3,12,15,16,17,18", then we display "1-3,12,15-18". In ideal case when all but one revision is executed we'll just have 1 range. This way version would look like: "5.2.1-B1 (r1-200)".

          Also we maybe want to reset revision number within version. So there can be 1st revision in each version. This way we can avoid crasy large numbers after few years.


          Don't hit ENTER after last comment line, because this creates margin (compare my and your comment), that only takes valuable screen place.

          1. Agreed - I think this will work great even for Custom module. I suggest we group non-deployed revisions too and highlight them in red color.

            1. At screen with module list it's not place to show what's not deployed. There we see current versions and revisions.

  2. Decided not to implement it as proposed, because it won't solve "huge upgrade script file" problem.