Page MenuHomePhabricator

Deprecate BagOStuff ATTR_EMULATION (use ATTR_DURABILITY)
Open, Needs TriagePublic

Event Timeline

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

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.

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?