Best way to upgrade portal database for new plugin version

[Morad Ahmad，修改在7 年前。]

Hi all,

I want to deploy a new version of my portlets project to a live environment. The project contains new DB-Tables generated with the ServiceBuilder.

Normally Liferay has an automatic upgrade where current DB-Tables exported as XML-Files, Tables dropped, new DB-Tables, Indizies etc. created
XML-Content import...

I want to avoid these procedure in Live env. So waht is the best way to do it?:

1. Use SQL-Scripts to create new tables and modify existing ones....
2 Use "UpgradProcess" to implement DB-Modifications required for the new version.

In these context I have an additional Question:

Normally the ServiceBuilder doesn't generate any foreign key constraints. However for many tables these is very important.
Is it a good praxis to add FK's manually to the DB-Schema?

Thanks,
Morad.

[David H Nebinger，修改在7 年前。]

Personally I believe the only time you should be letting SB create and manage tables is when you are developing a marketplace plugin.

Otherwise it is often better to let the DBA create tables. You have more control over table/column naming, index creation, PK & FK assignments, column type, sizing, default values, etc.

In this mode the service.xml file is merely used to define the mapping from the POJO to the tables.

[Morad Ahmad，修改在7 年前。]

Thanks David,

yes this is the case if you develop "special" portlets in a specific project. But when you develop a portlet for deployment in different environments then you must guarantee that DB is updated for the current version, and for different database servers/versions...

I didn't implement an "UpgradProcess" yet, but is it possible to create tables from a java class within such an UpgradeProcess? I see there is an "upgradeTable()" method in the base class?? AND There is an "public static final String TABLE_SQL_CREATE" in each Entity generated with the ServiceBuilder...

And Last Question The "service-ext.properties" is within the plugin itself. How can I, as an admin, although override the property "build.auto.upgrade=true" and set it to "false" if I deploy a third party plugin?

I didn't really understand the complete thing:-)

Regrads,
Morad.

[David H Nebinger，修改在7 年前。]

This is a typical project management issue that many projects face. Personally I think falling back to having SB do it is a short cut to good project management.

That said, sure you can create your own upgrade process, Liferay's upgrades rely on this same mechanism so admins don't need to do preparation before updating. It won't negate having DB-specific scripts if you are doing db-specific stuff (like with foreign keys), and having foreign keys enabled may make your upgrade process challenging, but you can leverage the Liferay utilities to help build out the upgrade process implementation.

So back to my own opinion thing again - if your team was using good project management including ensuring databases are updated at appropriate times, well then you wouldn't be wasting time building out a coding solution for an otherwise simple DBA task. So you keep your development resources focused on completing project requirements rather than paying to work around lack of project planning. Don't take this the wrong way, though, I'm not pointing fingers and I realize this might not be your call at all, I'm just trying to point out some aspects that others might consider when they're thinking about doing this.

The properties files, well those actually load from the class path. So you could put your service-ext.properties file in the same location as portal-ext.properties and it will be visible to the code. If you're concerned about using service-ext.properties if multiple service projects are deployed, you can go into the service.properties file in the service providing project and add an "include-and-override" line that uses a custom and unique name, just follow the format in there for the service-ext.properties inclusion.