updateSearchIndex has MySQLisms
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	• bzimport
	Jun 24 2009, 2:53 AM

Description

Author: overlordq

Description:
First off the strencode's for the timestamps on lines 63 && 64 dont call $dbw->timestamp to get a correctly formatted timestamp for various DB's.

Secondly, I know for sure MySQL and PG both have different LOCK TABLE syntax so locking tables might need abstracted out into the various database classes.

The very unhelpful lock/unlock methods already there only seem to check for named locks, not actually implementing locking and unlocking.

Version: 1.16.x
Severity: normal

Details

Reference: bz19372

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:40 PM

• bzimport added a project: MediaWiki-Maintenance-system.

• bzimport set Reference to bz19372.

• bzimport added a subscriber: Unknown Object (MLST).

• bzimport created this task.Jun 24 2009, 2:53 AM

(In reply to comment #0)

The very unhelpful lock/unlock methods already there only seem to check for
named locks, not actually implementing locking and unlocking.

Are you looking at the methods in DatabaseBase? lock() clearly acquires a lock (probably needs moving to DatabaseMysql and abstraction to other classes), and unlock() does the opposite.

Cleaned this up somewhat in r52.

I couldn't find the strencode() issue you mentioned, is this on trunk? Also, the SELECT query probably needs abstracting too, just didn't do that yet.

r52382 :D

overlordq wrote:

Lines 23&24 of updateSearchIndex.inc r52398

Select entries from recentchanges which are on top and between the specified times $start = $dbw->strencode( $start ); $end = $dbw->strencode( $end );

More mysqlisms in bug 18291?

Fixed as of r52477. Bug 18291 is not a blocker to this at all.

updateSearchIndex has MySQLismsClosed, ResolvedPublicActions

Description

Details

Event Timeline

updateSearchIndex has MySQLisms
Closed, ResolvedPublic
Actions