Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
So if someone wants to tackle this, here's approximately how I'd go about it:
* In the update process, before each update hook runs, start a new logger.
* After the update hook, stop the logger and grab its saved data. Store that to some data structure.
* Take the return from the update hook as an array of *extra* messages. Allow nothing to be returned, in which case there's no extra messages.
* When all hooks are done running, iterate through the data structure and make a list of each update hook and the queries it ran and any messages it returned.
Submit that patch first so we can get it committed. Then we can exterminate update_sql and modify the schema API to not bother with the stupid $ret array that gets passed around everywhere in separate patches.
Comments
Comment #1
moshe weitzman commentedComment #2
Crell commentedSo if someone wants to tackle this, here's approximately how I'd go about it:
* In the update process, before each update hook runs, start a new logger.
* After the update hook, stop the logger and grab its saved data. Store that to some data structure.
* Take the return from the update hook as an array of *extra* messages. Allow nothing to be returned, in which case there's no extra messages.
* When all hooks are done running, iterate through the data structure and make a list of each update hook and the queries it ran and any messages it returned.
Submit that patch first so we can get it committed. Then we can exterminate update_sql and modify the schema API to not bother with the stupid $ret array that gets passed around everywhere in separate patches.
So who wants to be a hero? :-)
Comment #3
moshe weitzman commented