Use batching for post update functions

Created on 11 October 2023, 12 months ago
Updated 23 October 2023, 11 months ago

Problem/Motivation

Running the post update functions on a large site with many fraction fields can time out the default PHP execution limit of around 30 seconds.

The batch api (via sandbox variable) is available for post update functions - split the functions up so that they run a single loop per field and can be run over multiple requests, bypassing the execution limit.

function hook_post_update_NAME(&$sandbox)
hook_post_update_NAME (10)

Steps to reproduce

Have a old site using 8.x-1.x branch with 50+ fraction fields and millions of rows of data; try to update to Fraction 2.x.

Proposed resolution

Re-write post update functions to use batched execution.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

✨ Feature request
Status

Closed: won't fix

Version

2.0

Component

Code

Created by

πŸ‡¦πŸ‡ΊAustralia elc

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @elc
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 8.1 & pgsql-13.5
    last update 12 months ago
    21 pass, 2 fail
  • @elc opened merge request.
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 8.1 & pgsql-13.5
    last update 12 months ago
    23 pass
  • Status changed to Needs review 12 months ago
  • πŸ‡¦πŸ‡ΊAustralia elc

    Tests needed to have a mocked Batch API style call for them to complete.

    As a note for anyone still updating a site from D8, using version 2.1.0 of the Fraction module (last version marked compatible) and the fraction.post_update.php from this merge to get the schema update completed if it times out. It is effectively the same file and source schema from back then.

  • Status changed to Closed: won't fix 11 months ago
  • πŸ‡ΊπŸ‡ΈUnited States m.stenta

    Thanks for contributing this @ELC!!

    However, because this is a significant change, and it changes an update hook (which only affects a very limited set of users), and the original issue is "fixed" for (hopefully) most users, and the number of users on 8.x-1.x is limited and dropping (according to usage statistics β†’ ), and I do not have the time to review and test it thoroughly myself, from a maintainer's perspective I'm inclined to just leave this MR as an option for others who need it, but close this issue as "won't fix".

    That said, if someone else runs into the same problem (hopefully not!), and they dig in and discover this issue, and they contribute some time to review and test it (to get another perspective and context as a form of due-diligence), then we can reopen and merge it. Does that seem fair?

    Credit where credit is due! Simply opening this issue and contributing the MR is a huge contribution! Thank you again!

Production build 0.71.5 2024