X-Git-Url: https://git.heureux-cyclage.org/?a=blobdiff_plain;f=includes%2Fdao%2FIDBAccessObject.php;h=a555c5527c8afb6da00c513889655b9bf43d9342;hb=9eb3834b898dd674d4d97ae0a61a2ff36ab01319;hp=3690735ed5bb4b482888a491408c8ea742cf16ac;hpb=b15bfd99a94d1dfd63af9c184abfd979155b927a;p=lhc%2Fweb%2Fwiklou.git

diff --git a/includes/dao/IDBAccessObject.php b/includes/dao/IDBAccessObject.php
index 3690735ed5..a555c5527c 100644
--- a/includes/dao/IDBAccessObject.php
+++ b/includes/dao/IDBAccessObject.php
@@ -29,31 +29,42 @@
  * 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 slave or stale replica)
+ *   - 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 master 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 master/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) Read the current row
- *   - b) Determine the new row (expensive, so we don't want to hold locks now)
- *   - c) Re-read the current row with READ_LOCKING; if it changed then bail out
- *   - d) otherwise, do the updates
+ *   - 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
  *
  * @since 1.20
  */
 interface IDBAccessObject {
-	// Constants for object loading bitfield flags (higher => higher QoS)
-	const READ_LATEST = 1; // read from the master
-	const READ_LOCKING = 3; // READ_LATEST (1) and "LOCK IN SHARE MODE" (2)
-	const READ_EXCLUSIVE = 7; // READ_LOCKING (3) and "FOR UPDATE" (4)
+	/** Constants for object loading bitfield flags (higher => higher QoS) */
+	/** @var int Read from a replica DB/non-quorum */
+	const READ_NORMAL = 0;
+	/** @var int Read from the master/quorum */
+	const READ_LATEST = 1;
+	/* @var int Read from the master/quorum and lock out other writers */
+	const READ_LOCKING = self::READ_LATEST | 2; // READ_LATEST (1) and "LOCK IN SHARE MODE" (2)
+	/** @var int Read from the master/quorum and lock out other writers and locking readers */
+	const READ_EXCLUSIVE = self::READ_LOCKING | 4; // READ_LOCKING (3) and "FOR UPDATE" (4)
 
-	// Convenience constant for callers to explicitly request slave data
-	const READ_NORMAL = 0; // read from the slave
+	/** @var int Read from a replica DB or without a quorum, using the master/quorum on miss */
+	const READ_LATEST_IMMUTABLE = 8;
 
 	// Convenience constant for tracking how data was loaded (higher => higher QoS)
 	const READ_NONE = -1; // not loaded yet (or the object was cleared)