[wp-trac] [WordPress Trac] #12021: Default database create SQL makes invalid assumptions about primary key values

WordPress Trac wp-trac at lists.automattic.com
Mon Jan 25 20:27:23 UTC 2010


#12021: Default database create SQL makes invalid assumptions about primary key
values
--------------------------+-------------------------------------------------
 Reporter:  wpmuguru      |       Owner:            
     Type:  defect (bug)  |      Status:  new       
 Priority:  normal        |   Milestone:  Unassigned
Component:  Multisite     |     Version:            
 Severity:  normal        |    Keywords:            
--------------------------+-------------------------------------------------
 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12021>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list