Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-26361

cleanupversions.php does not scale on large amounts of versions

    Details

    • Type: Improvement Improvement
    • Status: Backlog
    • Priority: High High
    • Resolution: Unresolved
    • Affects Version/s: 5.3.10, 5.4.8
    • Fix Version/s: Customer request
    • Component/s: Database related
    • Labels:
      None

      Description

      On legacy, it is possible to limit the number of content versions that are created through settings ("DefaultVersionHistoryLimit", "VersionHistoryClass"). On the Public API, no such mechanism exists, and users are free to create as many content versions as they like, either accidentally or by design. At some point, it might be necessary to cleanup all that clutter from the database, and the cleanupversions.php script has been created with that task in mind.

      However, since there is not a content version limit in the Public API, a single content can have many versions, potentially tens of thousands of versions or even more.

      The cleanupversions.php script just isn't robust enough to deal with this amount of clutter, it simply hasn't been designed to deal with such big cleanups. Please create an alternative script capable of cleaning up large amounts of content versions, in a reasonable amount of time.

        Issue Links

          Activity

          Hide
          Yannick Roger (Inactive) added a comment -

          This is not supposed to happen with a regular usage of the application. The only was to end up in this situation is with a buguy custom code. That's why it can not be considered as a bug. I am changing this to an improvement.

          If you are running into this kind of situation (huge amount of versions) because of custom code, you need to find a custom and optimized way to fix it on your setup or load a backup of your data.
          The Professional Services of eZ can also most likely provide help for this kind of custom matters.

          Show
          Yannick Roger (Inactive) added a comment - This is not supposed to happen with a regular usage of the application. The only was to end up in this situation is with a buguy custom code. That's why it can not be considered as a bug. I am changing this to an improvement. If you are running into this kind of situation (huge amount of versions) because of custom code, you need to find a custom and optimized way to fix it on your setup or load a backup of your data. The Professional Services of eZ can also most likely provide help for this kind of custom matters.

            People

            • Assignee:
              Unassigned
              Reporter:
              Nuno Oliveira (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: