#12021 closed defect (bug) (fixed)
Default database create SQL makes invalid assumptions about primary key values
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | 3.0 | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Multisite | Keywords: | |
| Focuses: | Cc: |
Description
MU Trac Ticket: http://trac.mu.wordpress.org/ticket/1123
See http://mu.wordpress.org/forums/topic/14691
We're hosting our WPMU install on an internal cluster of machines, and the dev DB server we're testing this on used to be part of a Master-Master setup, so its autoincrement values were set to increment in 10s, starting with 2.
Since the blog and site creation SQL sends a NULL value to the ID field (a reasonable thing to do on an insert), the autoincrement value gets set to whatever the server thinks it should be. However, the source of this particular problem is because the successive inserts assume this value will be 1 on a fresh install.
While this is a strange case, it's certainly not out of the realm of other setups, and could easily be addressed by doing a select on the id of the first site and blog created, instead of assuming values of 1.
*I've attached a patch to remedy the situation.*
Another related bug is the fact that wp-admin/includes/schema.php is include_once()'d (via upgrade.php) in index-install.php immediately after step2(). Then immediately after, during step3(), when the value of the $wpdb->xxxx table names should contain the right blog id, it's include_once()'d again to get the right CREATE statements. However, since it had already been include_once()'d, it is ignored the second time, making its inclusion at that point useless.
I've put this code into a function that may be called at will to repopulate the $wp_queries global variable with the correct values for table names.
Related ticket #11816