Liferay 7.3 - Auto upgrade of custom services

Question

I have a custom service module (myproject-service & myproject-api).

With Liferay 7.2 and previous versions, when I changed my database model (for exemple : add a new column in a table in the service.xml), I used an UpgradeProcess and an UpgradeStepRegistrator, with an incrementation of the Liferay-Require-SchemaVersion.

Since the 7.3 version, the autoupgrade has been moved to a property and changed to false value. In developpement, this value is true and everything works fine but in production, my custom service doesn't upgrade now at server start.

Is there a solution to make this system works again automatically ? I've seen that now we have to do the upgrade manually in the gogo shell with upgrade:execute command.

Answer 1

You are probably looking for

Set this to true to execute the upgrade process when the portal starts and modules are activated.

upgrade.database.auto.run=false

You still need to build the "upgradeProcess", as in: https://help.liferay.com/hc/en-us/articles/360018162851-Creating-Data-Upgrade-Processes-for-Modules-

Answer 2

Technically, you could activate the same property in production systems. However, this is neither safe, nor performant: The solution for table updates is generic and (as far as I know) will

1. export your table's data,
2. DROP TABLE,
3. CREATE TABLE (with the new structure)
4. populate the table with the previously saved data.

Now, apart from this being horribly slow for large amounts of data, there are some other shortcomings:

• if you have renamed a column, or
• added a non-nullable column,

this would fail to do the work as you expected it (even in development).

Further:

• If this process is interrupted at any time, you might lose all of your data

In many cases, a simple ALTER TABLE xxx ADD COLUMN yyy would be sufficient, and is quick, safe and easy to do within SQL. That's where your UpgradeProcess kicks in. You wouldn't want to do that after every little bit in development (hence the property), but you certainly don't want to DROP TABLE with important data in production, and wait for who-knows-how-long, when there was just a trivial change.

From that point of view: You want to write a custom UpgradeProcess, even if you don't know that you do. And there's even a great starting point, that takes away the repetitive and low level work.