Change 677064 had a related patch set uploaded (by Krinkle; author: Aaron Schulz):

[mediawiki/core@master] objectcache: Switch SqlBlobStore to using ATTR_DURABILITY

https://gerrit.wikimedia.org/r/677064

Change 677064 merged by jenkins-bot:

[mediawiki/core@master] objectcache: Switch SqlBlobStore to using ATTR_DURABILITY

https://gerrit.wikimedia.org/r/677064

Ref T281480: SqlBlobStore no longer caching blobs (DBConnectionError Too many connections)

Change 685613 had a related patch set uploaded (by Aaron Schulz; author: Aaron Schulz):

[mediawiki/core@master] objectcache: deprecate ATTR_EMULATION/QOS_EMULATION_SQL

https://gerrit.wikimedia.org/r/685613

Change 683691 had a related patch set uploaded (by Krinkle; author: Aaron Schulz):

[mediawiki/core@master] objectcache: set all ATTR_* flags for BagOStuff classes

https://gerrit.wikimedia.org/r/683691

Last month I reviewed these changes, indicating that it seems to me the boolean QOS_EMULATION_SQL attribute appears to be the only one of all these key/value attributes that we actually need.

Specifically, because T186673 hasn't been resolved yet, MediaWiki uses CACHE_NONE by default and we don't have a clear policy on whether it is better or worse to set the main cache to CACHE_DB vs nothing at all. My general impression is that for a small traffic wiki it probably helps to enable caching even if just using a local (non-sqlite) database. But there are is basically one major thing where we currently think it's worth explicitly avoiding use of the main cache if it happens to be configured to CACHE_DB, and that's the storing of revision text (SqlBlobStore). What we do there is we obtain the main cache (wrapped in WANCache) and ignore it if it's backed by a SQL database.

I was unable to find any current use of these attributes in our code bases.

@aaron writes at change 683691:

ATTR_SYNCWRITES is useful to check things like SessionBackend that use SYNC_WRITES.
ATTR_LOCALITY can be used with ATTR_DURABILITY to avoid slow caches.

Are these theoretical or current? For SessionBackend checking, do you mean that an extension that stores something in SessionBackend, would split its logic (beyond the documented requirements) and vary its behaviour at runtime based on whether the site administrator has configured a session backend that does vs doesn't support SYNC_WRITES? I note that the documented requirements currently state that SessionBackend (and by extent core more generally) expects SYNC_WRITES to be supported, so this would be at odds with that. If that is going to change, what kind extensions would you expect to use this and why?

Change 714403 had a related patch set uploaded (by Aaron Schulz; author: Aaron Schulz):

[mediawiki/core@master] Remove StorageAwareness::ATTR_EMULATION

https://gerrit.wikimedia.org/r/714403

Hey there. This task is proposed as a blocker to MediaWiki 1.37, which will be cut in less than three weeks' time. Please consider whether this will make that deadline, and if not, move it to block the MediaWiki 1.38 release (MW-1.38-release) or remove as a blocker entirely.

Change 683691 merged by jenkins-bot:

[mediawiki/core@master] objectcache: simplify BagOStuff::ATTR_* flags and set them for backends

https://gerrit.wikimedia.org/r/683691

Change 685613 abandoned by Aaron Schulz:

[mediawiki/core@master] objectcache: deprecate ATTR_EMULATION/QOS_EMULATION_SQL

Reason:

https://gerrit.wikimedia.org/r/685613

Change 714403 abandoned by Krinkle:

[mediawiki/core@master] Remove StorageAwareness::ATTR_EMULATION

Reason:

Ref T279977

https://gerrit.wikimedia.org/r/714403

Change 685613 restored by Aaron Schulz:

[mediawiki/core@master] objectcache: deprecate ATTR_EMULATION/QOS_EMULATION_SQL

https://gerrit.wikimedia.org/r/685613

Change 685613 merged by jenkins-bot:

[mediawiki/core@master] objectcache: deprecate ATTR_EMULATION/QOS_EMULATION_SQL

https://gerrit.wikimedia.org/r/685613