Submit Feedback
Legacy Knowledge Base
Published Jun. 30, 2025

Upgrade to 7.4: DDMFieldUpgradeProcess takes an awfully long time

Written By

Sorin Pop

How To articles are not official guidelines or officially supported documentation. They are community-contributed content and may not always reflect the latest updates to Liferay DXP. We welcome your feedback to improve How To articles!

While we make every effort to ensure this Knowledge Base is accurate, it may not always reflect the most recent updates or official guidelines.We appreciate your understanding and encourage you to reach out with any feedback or concerns.

Legacy Article

You are viewing an article from our legacy "FastTrack" publication program, made available for informational purposes. Articles in this program were published without a requirement for independent editing or verification and are provided"as is" without guarantee.

Before using any information from this article, independently verify its suitability for your situation and project.

Issue

  • We are upgrading to 7.4 and noticed that the upgrade process is working a lot at DDMFieldUpgradeProcess, this part seems to be taking a very long time

Environment

  • upgrade to 7.4

Resolution

  • This is known. It happens because this process normalizes the json or xml data from the ddmcontent table, rips it apart into small pieces and puts them into two new tables: ddmfield and ddmfieldattribute tables. This can indeed take a long time, depending on the amount of records and data in your original ddmcontent table.
  • However, there are a few things you can do to possibly make it a bit faster.
  • https://liferay.atlassian.net/browse/LPS-187207 has introduced a certain degree of performance improvement in this upgrade process. This change should be included in a later, recent quarterly release, so we recommend to get a recent quarterly release (e.g. 2023.q4.2 at the time of writing thsi article) and perform the upgrade to that, run the upgrade script from that. Hopefully the DDMFieldUpgradeProcess will be somewhat faster, but it might still need a long time, depending on the amount of data it has to process.
  • In order to possibly avoid the process failing with OutOFMemory issues, I suggest to start the upgrade script with ample memory, please see this documentation on how to do that.
  • It might also help to use a large defaultFetchSize JDBC setting in the db connection url setting, so that during the upgrade, it fetches more rows at once, in one chunk. This could also help with the faster processing.
     
    To be more exact, try adding a part liek this:     
     
    &callableStmtCacheSize=10000&cacheCallableStmts=true&defaultFetchSize=10000000&enableQueryTimeouts=false

          to the jdbc.default.url property in portal-upgrade-database.properties (and portal-ext.properties). You can play with the defaultFetchSize value, the above is just an example 10000000 might be too large for your needs. After the upgrade process completes, you can remove this part from portal-ext.

Did this article resolve your issue ?
Legacy Knowledge Base
Did this article resolve your issue ?