Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.There have been some reports (#2188277: "cache_panels doesn't exist" error on update) that the {cache_panels} table isn't being created properly in update 7303. In some cases it seems like update 7302 fails to finish, so it never gets to add the table. I think the logic in update 7302 should be changed to use a batch update instead of a single action, just to help ensure the update finishes correctly. Alternatively it could be split out into separate updates, one for each type of record.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | interdiff_7-9.txt | 837 bytes | azinck |
| #9 | panels-change_update_7302-2192993-9.patch | 6.34 KB | azinck |
| #7 | interdiff_4-7.txt | 3.55 KB | heddn |
| #7 | panels-change_update_7302-2192993-7.patch | 6.18 KB | heddn |
Comments
Comment #1
heddnWith 33,119 panels displays and growing by the day on a specific site, I think we need to use $sandbox, or something. This just doesn't scale any other way.
The hook update loads every. single. panels display. on the site. That sucks.
Comment #2
azinck CreditAttribution: azinck commentedYeah, this is a major problem, especially for those of us using Panelizer. The way this is currently written every single Panels display on the site is loaded at once! In our case we currently have 10's of thousands of displays. This is not tenable.
Comment #3
azinck CreditAttribution: azinck commentedHere's a stab at it. Batching 200 at a time. It might be overly conservative but it works for me.
Comment #4
heddnThis addresses a few pain points.
Comment #5
heddnJust a note, drupal_write_record is a bad thing to use on in a hook_update. I think we are OK with flushing schema cache 99% of the time. However, if the panels save triggers some other drupal_write_record for another schema backed entity/thing, then we could still be in trouble.
See note in https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_.... Why am I focusing on drupal_write_record? Because panels_save_display ends up calling it.
Because of its use, I'm bumping this to a major.
Comment #6
DamienMcKennaChanging to Needs Work based upon @heddn's comment.
Comment #7
heddnSwitches this over to direct db calls instead of using drupal_write_record. I opted not to call all the overhead of module_invoke_all and watchdog that were in panels_save_display. I think those are unnecessary and add extra weight to something that is already pretty heavy-handed.
Comment #8
heddnBump
Comment #9
azinck CreditAttribution: azinck commentedThe patch in #7 is subject to a long-standing bug with the use of DISTINCT and certain versions of MySQL: http://bugs.mysql.com/bug.php?id=30402
The COUNT() query that determines how many records there are to process can (incorrectly) return 0 on some versions of MySQL. Here's a version of the patch that rewrites the query to avoid that problem.
Comment #10
DamienMcKennaWould it be worth adding another update script to rerun update 7302 for sites that had to shoe-horn past it to make it finish the first time?
Comment #11
azinck CreditAttribution: azinck commentedSince this has sat here for over a year with few complaints maybe it's not worth taking on that risk? I don't feel strongly.