Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-44874

Upgrade process in sharded environment is not accessing the default shard when needed

    Details

      Description

      Upgrading in a sharding environment should take into account that some data must be read/written from/to the default shard, regardless the shard we are upgrading in a specific moment.

      More specifically:

      • When upgrading PortletPreferences to 6.0.12 and later, some of them become PortalPreferences and go to the default shard. But originally, they are stored in PortletPreferences on different shards. As a result, we get data written to different PortalPreferences tables on different shards, which is wrong. Data has to be moved from the PortletPreferences table on each shard to the PortalPreference table on the default shard.
      • When upgrading community virtual hosts to 6.0.12 and later, the virtualhost is moved from LayoutSet (all shards) to VirtualHost table (always default shard). As a result, we get different VirtualHost tables in different shards, which is wrong.
      • When upgrading Groups to 6.1 and later, they turn into Sites if they have a specific className. ClassName has to be read from the default shard, otherwise, Groups living in non-default shards will never turn into sites. As a result, non-default shard instances won't show anything in the control panel sites menu.
      • In addition, when ClassName is not read from the default shard, more side effects might happen, as there are several upgrade processes which rely on data read from this table.
      • When upgrading journal articles to 7.0.0, a basic web content structure is created. The process fail as described in LPS-45989 (closed as duplicates this LPS)
      • Bitwise values have to be read from the ResourceAction table in the default shard. This applies when upgrading "Access In Control Panel" permissions to 6.1.0, and when upgrading IG to DL permissions to 6.1.0

      This should only apply to DML operations (insert, select, update) but not to DDL operations (create index, drop table, etc) as tables exist in all shards but only contain data in the default one.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jorge.ferrer Jorge Ferrer
                Reporter:
                daniel.sanz Daniel Sanz
                Participants of an Issue:
                Recent user:
                Jorge Ferrer
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  2 years, 42 weeks, 2 days ago

                  Packages

                  Version Package