r52466 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:r52465‎ | r52466 | r52467 >
Date:15:38, 26 June 2009
Author:ialex
Status:resolved (Comments)
Tags:
Comment:
same as r52457 but for SQLite
Modified paths:
  • /trunk/phase3/includes/db/DatabaseSqlite.php (modified) (history)

Diff [purge]

Index: trunk/phase3/includes/db/DatabaseSqlite.php
@@ -404,7 +404,7 @@
405405 /**
406406 * No-op lock functions
407407 */
408 - public function lock( $lockName, $method ) {
 408+ public function lock( $lockName, $method, $timeout = 5 ) {
409409 return true;
410410 }
411411 public function unlock( $lockName, $method ) {
@@ -455,6 +455,10 @@
456456 /** No-op */
457457 public function setBigSelects( $value = true ) {}
458458
 459+ public function lockTables( $read, $write, $method ) {}
 460+
 461+ public function unlockTables( $method ) {}
 462+
459463 } // end DatabaseSqlite class
460464
461465 /**

Past revisions this follows-up on

RevisionCommit summaryAuthorDate
r52457quick fix for r52382: fix errors in DatabasePostgres, lock() has incompatible...ialex13:25, 26 June 2009

Comments

#Comment by Simetrical (talk | contribs)   22:37, 26 June 2009

Is it reasonable to just skip the table locking? Where are the callers, and will they be broken by not locking? If the callers will really be broken by not locking, then better to get a fatal error with pgsql/SQLite. If they won't, then this doesn't really need to be overridden, so the default DatabaseBase method should just be a no-op.

#Comment by IAlex (talk | contribs)   13:06, 27 June 2009

The only file using these methods is maintenance/updateSearchIndex.inc, which locks the searchindex table for writing and page, revision, text and interwiki for reading (with unlock/lock beetween each update). I dunno how it would work on PG (SQLite has no fulltext index).

#Comment by Simetrical (talk | contribs)   02:33, 28 June 2009

Definitely sounds like this should be made optional to implement, and a no-op by default.

Status & tagging log