Last modified: 2009-07-20 02:00:13 UTC
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.
(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
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.
