Ask Questions and Find Answers

There are Upgrade Processes available that make performing crucial, non-trivial actions easier, like changing a Portlet's Id (ex: upgrading from 6.2 to 7.x), or updating Portlet Preferences.

These Upgrade Processes, like many others, work using SQL Updates.

See https://github.com/liferay/liferay-portal/blob/29b73b9b896c7d44fb5d1800a402698c303d1cf6/portal-kernel/src/com/liferay/portal/kernel/upgrade/BaseUpgradePortletId.java#L320 and https://github.com/liferay/liferay-portal/blob/29b73b9b896c7d44fb5d1800a402698c303d1cf6/portal-kernel/src/com/liferay/portal/kernel/upgrade/BaseUpgradePortletPreferences.java#L205

This point goes against one of the most important rules of Liferay Development: Always use the Service Layer / Model Objects / Hibernate to persist; Never update the database directly * .

​​​​​Now every rule has exceptions, and the use of SQL to make the staggering number of changes to needed to Upgrade from 6 to 7 makes perfect sense.  I suspect that the Upgrade Tool makes this easier by running the Server in a "special" mode, where Hibernate is disabled or runs differently (among other things).

But what about Upgrade Processes that update Base Liferay Tables during normal Server use, like with custom Bundles?

For example: Say I have an Upgrade Step that extends BaseUpgradePortletId to convert a 6.2 Portlet to 7.3:

registry.register( "0.0.0", "0.0.1",
    new BaseUpgradePortletId() {
        protected String[][] getRenamePortletIdsArray() {
            return new String[][] {
                {"myportlet_WAR_myportletplugin", MyPortletKeys.MyPortlet}
            };
        }
    }
);

When it fires and makes changes to heavily used base tables (like Layout, PortalPreference, ResourcePermission, etc) with SQL, presumably any cached Model Objects are now out of sync, and if those cached Objects are ever persisted, the SQL-induced changes will be lost.

So my question is: How do SQL changes like these not conflict with cached Model Objects / Hibernate? Or, are conflicts being introduced, and that my team has been fortunate enough to not encounter them?

(This is a question that's been nagging at me for a couple years now.)

*unless you know what you are doing.