WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 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 5 years ago.

Download all attachments as: .zip

Change History (12)

@mitchoyoshitaka5 years ago

comment:1 @mitchoyoshitaka5 years ago

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

comment:2 follow-up: @nacin5 years ago

What's the table statement?

comment:3 @Denis-de-Bernardy5 years ago

  • Keywords reporter-feedback added

comment:4 in reply to: ↑ 2 @mitchoyoshitaka5 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.

comment:5 follow-up: @westi5 years ago

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

Ok. I can reproduce this.

Investigating

comment:6 in reply to: ↑ 5 @mitchoyoshitaka5 years ago

Replying to westi:

Ok. I can reproduce this.

Investigating

Thanks. :)

comment:7 @westi5 years ago

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

comment:8 @mitchoyoshitaka5 years ago

  • Milestone changed from Unassigned to 3.0

comment:9 @nacin5 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.

comment:10 @nacin5 years ago

  • Keywords needs-unit-tests added

really-needs-unit-tests :-)

comment:11 @nacin5 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.