WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#13715 closed defect (bug) (fixed)

dbDelta produces warnings

Reported by: mitchoyoshitaka Owned by: westi
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: Database Keywords: has-patch needs-unit-tests
Focuses: Cc:

Description

I just followed the instructions on the Codex to use dbDelta to create and update tables, and I'm getting the following warning:

Warning: array_search() [function.array-search]: Wrong datatype for second argument in /Users/mitcho/wordpress/wp-admin/includes/upgrade.php  on line 1526

It looks like $indices is never being initialized as an array. The attached patch works, but I'm not familiar with the dbDelta logic so it'll need review from someone who does.

Attachments (1)

13715.diff (577 bytes) - added by mitchoyoshitaka 10 years ago.

Download all attachments as: .zip

Change History (12)

#1 @mitchoyoshitaka
10 years ago

  • Component changed from General to Database
  • Owner set to ryan

#2 follow-up: @nacin
10 years ago

What's the table statement?

#3 @Denis-de-Bernardy
10 years ago

  • Keywords reporter-feedback added

#4 in reply to: ↑ 2 @mitchoyoshitaka
10 years ago

  • Keywords reporter-feedback removed

Replying to nacin:

What's the table statement?

Here's my code:

		require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );
		
		$dbSql = array(
						"CREATE TABLE `{$this->db_prefix}visitors` (
							`visitor_id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
							`cookie` BINARY(16) NOT NULL UNIQUE KEY ,
							`timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
						) ENGINE = MYISAM ;");
		dbDelta( $dbSql );

where of course $this->db_prefix actually resolved to something involving $wpdb->prefix. I'm using an array because there actually are multiple, but I can reproduce this even with that first query.

#5 follow-up: @westi
10 years ago

  • Owner changed from ryan to westi
  • Status changed from new to accepted

Ok. I can reproduce this.

Investigating

#6 in reply to: ↑ 5 @mitchoyoshitaka
10 years ago

Replying to westi:

Ok. I can reproduce this.

Investigating

Thanks. :)

#7 @westi
10 years ago

Note to self: To reproduce I created the table using the above and then duplicating the fields.

#8 @mitchoyoshitaka
10 years ago

  • Milestone changed from Unassigned to 3.0

#9 @nacin
10 years ago

Committing this now.

Mitcho, you'll actually have a separate issue with your create table statement, in that you'll end up with duplicate cookie indexes each time it runs.

The issue is that dbDelta is incredibly finicky and requires exacting specifications in some cases, and sometimes throwing a fight over whitespace. The Codex is pretty good about explaining this, and otherwise sticking to the queries that core use is a good bet.

In this case, defining UNIQUE KEY with the cookie field is causing dbDelta to keep creating indexes. I did not look into why, but moving UNIQUE KEY cookie (cookie) to its own line at the end of the statement fixed it.

#10 @nacin
10 years ago

  • Keywords needs-unit-tests added

really-needs-unit-tests :-)

#11 @nacin
10 years ago

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

(In [15210]) Reset variables back to empty arrays instead of unsetting them in dbDelta. prevents a warning. props mitchoyoshitaka, fixes #13715.

Note: See TracTickets for help on using tickets.