MediaWiki 1.41.2
Public Attributes | List of all members
IDBAccessObject Interface Reference

Interface for database access objects. More...

Inherited by DBAccessObjectUtils, File, MediaWiki\Page\PageLookup, MediaWiki\Revision\RevisionFactory, MediaWiki\Revision\RevisionLookup, MediaWiki\Revision\RevisionStore, MediaWiki\Storage\DerivedPageDataUpdater, MediaWiki\Storage\SqlBlobStore, MediaWiki\Title\Title, MediaWiki\User\BotPassword, MediaWiki\User\BotPasswordStore, MediaWiki\User\CentralId\CentralIdLookup, MediaWiki\User\UserFactory, MediaWiki\User\UserGroupManager, MediaWiki\User\UserIdentityLookup, MediaWiki\User\UserOptionsLookup, and WikiPage.

Public Attributes

const READ_NONE = -1
 Constants for object loading bitfield flags (higher => higher QoS)
 

Detailed Description

Interface for database access objects.

Classes using this support a set of constants in a bitfield argument to their data loading functions. In general, objects should assume READ_NORMAL if no flags are explicitly given, though certain objects may assume READ_LATEST for common use case or legacy reasons.

There are four types of reads:

  • READ_NORMAL : Potentially cached read of data (e.g. from a replica DB or stale replica)
  • READ_LATEST : Up-to-date read as of transaction start (e.g. from primary or a quorum read)
  • READ_LOCKING : Up-to-date read as of now, that locks (shared) the records
  • READ_EXCLUSIVE : Up-to-date read as of now, that locks (exclusive) the records All record locks persist for the duration of the transaction.

A special constant READ_LATEST_IMMUTABLE can be used for fetching append-only data. Such data is either (a) on a replica DB and up-to-date or (b) not yet there, but on the primary/quorum. Because the data is append-only, it can never be stale on a replica DB if present.

Callers should use READ_NORMAL (or pass in no flags) unless the read determines a write. In theory, such cases may require READ_LOCKING, though to avoid contention, READ_LATEST is often good enough. If UPDATE race condition checks are required on a row and expensive code must run after the row is fetched to determine the UPDATE, it may help to do something like:

  • a) Start transaction
  • b) Read the current row with READ_LATEST
  • c) Determine the new row (expensive, so we don't want to hold locks now)
  • d) Re-read the current row with READ_LOCKING; if it changed then bail out
  • e) otherwise, do the updates
  • f) Commit transaction
Stability: stable
to implement
Since
1.20

Definition at line 57 of file IDBAccessObject.php.

Member Data Documentation

◆ READ_NONE

const IDBAccessObject::READ_NONE = -1

Constants for object loading bitfield flags (higher => higher QoS)

Definition at line 75 of file IDBAccessObject.php.

The documentation for this interface was generated from the following file: