Resolution: Won't Fix
Affects Version/s: 6.1.20 EE GA2, 6.1.30 EE GA3, 6.2.10 EE GA1
Fix Version/s: None
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.
- 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.