WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#14221 closed enhancement (fixed)

Allow disabling alterations to global tables during upgrade.

Reported by: ryan Owned by:
Milestone: 3.0.1 Priority: normal
Severity: normal Version: 3.0
Component: General Keywords:
Focuses: Cc:

Description

Sites that have large global tables (particularly users and usermeta) as well as sites that share their user tables with bbPress and other WP installs need to be able to prevent the WP upgrade from changing those tables during upgrade. An ALTER or an unbounded DELETE or UPDATE can take a long time to complete. Large sites usually want to avoid these being run as part of the WP upgrade so they can handle it themselves. Further, if you are sharing user tables between multiple bbPress and WP installs you might want one site to be the upgrade master. Let's introduce a DO_NOT_UPGRADE_GLOBAL_TABLES define that prevents dbDelta() and the upgrade functions from doing expensive queries against global tables.

Attachments (1)

14221.diff (1.7 KB) - added by ryan 4 years ago.

Download all attachments as: .zip

Change History (7)

ryan4 years ago

comment:1 wpmuguru4 years ago

I like this. We do have to do something for network install which needs to add the spam & deleted columns to the user table.

comment:2 ryan4 years ago

  • Milestone changed from Awaiting Review to 3.0.1

comment:3 ryan4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [15375]) Introduce DO_NOT_UPGRADE_GLOBAL_TABLES. fixes #14221 for 3.0.1

comment:4 ryan4 years ago

[15374] for trunk.

comment:5 ryan4 years ago

Someone doing a network install needs to make sure DO_NOT_UPGRADE_GLOBAL_TABLES isn't set. Blocking an MS install from changing the user table is a primary motivation for this. :-)

comment:6 Denis-de-Bernardy4 years ago

I feel this is incomplete...

Imo, we should introduce a separate db version option, as in the db version of the global table, when this is around. When the define is present, the upgrader should supply some kind of link that forces the global table's upgrade to occur (aka once everything else is upgraded properly), and upgrade this option accordingly once the global tables are indeed upgraded.

Note: See TracTickets for help on using tickets.