Page MenuHomePhabricator

[Refactoring] Use PSR-6 interfaces in caching services again
Open, Needs TriagePublic

Description

History

In this change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/498348, we ended up changing signature of cache-aware services to accept WANObjectCache instead of BagOfStuff.

BagOfStuff is our interface that implements PSR-6 Cache Interfaces. With this change, we narrowed down the dependency of those services to a certain provider that neither implements BagOfStuff nor implements PSR-6.

There was a reason to accept this change temporarily to solve some performance-related issue that we faced on Wikidata, though that change is not the most appropriate for wider-range of Wikibase users.
related comment on the patch

Objective

We want cache-aware services in Wikibase to depend again on either BagOfStuff or PSR-6 interfaces. To do that without interrupting Wikidata's need for using the functionality of WANObjectCache, we will have to:

  • find a way to make WANObjectCache implement PSR-6 or BagOfStuff
  • allow configuring which implementation is used easily per wikibase instance, if that's not the case already.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 26 2019, 8:45 AM

I don't think we will be able to expose the bits of WANCache that we need in some places through an interface such as PSR6 or bagostuff.
For the places where we do need such complex set get delete purge etc logic for caching for a multi DC situation we will have to write the code to use the WANCache interface, or something like it.
As we already have to write that logic, I'm not sure I see the value in then also allowing either a regular bagostuff or psr6 thing here.
At the end of the day one can create a WANObjectCache instance that just contains a single bagostuff as far as I know, rather than having code in wikibase do different types of caching based on the interface passed in.

Another thing to note is that WANObjectCache and BagOStuff both live in a mediawiki libs dir, which might one day actually be split out into its own composer package https://github.com/wikimedia/mediawiki/tree/master/includes/libs/objectcache T146257

The objective described is "We want cache-aware services in Wikibase to depend again on either BagOfStuff or PSR-6 interfaces."
I think this ticket aim could be clarified with the reason for that objective being desired to make it clearer why this should possibly be done.

The reason behind having a wider and standard interface here is that other use cases of Wikibase can be configured to use any implementation of PSR6 caching.

It can prove to be difficult or impossible to do, but I remember having a vague idea on how to do it when I created this task. I'll need to spend again some time thinking about it now and write up any useful hints if any comes to mind. It can be anyway taken as a nice excercise on how/whether we can find solutions to decouple Wikibase code base from Wikidata special needs and make things use more standards to allow portability of Wikibase. I think I also thought of that kind of learning as valuable at the time.

So, we are always leaning toward decoupling as much as possible from mediawiki itself, simply to make development easier.
However, that is not to say that the way we need to do this is to convert everything to use PSR-6 for example.
Right now the easier way to decouple Our caching services from mediawiki would simply be to wait for the caching service to finish being pulled out of mediawiki, i think this is mainly tracked under T146257.

In theory already a user of mediawiki or wikibase can configure their WANObjectCache to be backed by a BagOStuff which just points to a PSR6 cache, so in theory.

For those reasons I think the objective of this ticket is probably slightly wrong? Would a generic "Wikibase should only use liberalized cache services" be a nicer initial step?

But if we find a way to wrap WANObjectCache into PSR6 compliant interface won't that be even better.. esp. that BagOfStuff is already compliant. I mean then we remove the direct dependency in our interfaces on that library entirely.

I'd move it to on hold to watch the progress on T146257 for a little while and then decide whether we really want to wait on that or decouple from it completely?

But if we find a way to wrap WANObjectCache into PSR6 compliant interface won't that be even better.

I havn't thought much about how to do this, but it sounds complicated, as WANObjectCache is just not as simple as PSR6.

I mean then we remove the direct dependency in our interfaces on that library entirely.

Perhaps, but as long as we are a mediawiki extension, that library will always be there.

I'd move it to on hold to watch the progress on T146257 for a little while and then decide whether we really want to wait on that or decouple from it completely?

On hold sounds good to me. I can see reasons in the future that might mean we want to decouple, but right at this second, I don't think it brings us much value, unless we have a focused goal as part of a roadmap that is decoupling, which might happen in the future, but isn't happening right now.