$scope
$scope : \Drupal\strata\Capture\CaptureScope
Decides whether one ephemeral key is captured, and whether a restore writes it back.
Two questions have to agree before an ephemeral key is recorded: is the realm captured at all, and is this particular key worth capturing. The first is a configuration switch and the second is a classification, and they live in different places for a reason - the switch is read on every mutation and must not touch the database, while the classification is stored and must. This is where the two meet.
On a site with no Redis this answers almost nothing, and that is correct. Drupal's default
queue, semaphore, flood and session backends are TABLES, so the authoritative parts of the
ephemeral keyspace are already captured through Realm::TABLE by the statement tap and the
reconciler. Realm::EPHEMERAL exists for the case where a backend is not the database, which in
practice means Redis. Capturing a database-backed queue twice - once as a table and once as an
ephemeral key - would double its cost and give a restore two disagreeing copies.
$scope : \Drupal\strata\Capture\CaptureScope
$classifications : \Drupal\strata\Capture\Classifier\ClassificationRegistry
__construct(\Drupal\strata\Capture\CaptureScope $scope, \Drupal\strata\Capture\Classifier\ClassificationRegistry $classifications) : mixed
Constructs a scope.
| \Drupal\strata\Capture\CaptureScope | $scope | Whether the ephemeral realm is captured at all. |
| \Drupal\strata\Capture\Classifier\ClassificationRegistry | $classifications | What each part of the keyspace has been decided to be. |
restores(string $key) : bool
Whether a restore writes an ephemeral key back.
Stricter than capture on purpose. A key is stored when nothing has ruled it out, and written back only when something has ruled it in: writing an unrecognised ephemeral value over a live one during a restore is help nobody asked for, and the data it describes rebuilds it anyway.
| string | $key | The key. |
TRUE only when the key is classified authoritative.