The EntityChange class in Lib references the EntityContent class from Repo – it casts Content it receives as an argument to that class. We want to avoid direct Lib→Repo references like that.
|Resolved||Lucas_Werkmeister_WMDE||T255880 Remove uses of PHP classes from Wikibase Repo in Client and Lib|
|Resolved||Lucas_Werkmeister_WMDE||T255883 Don’t reference WikibaseRepo EntityContent class in WikibaseLib’s EntityChange|
In T255110#6224767, I outlined three ways to achieve this; I’ll summarize them here:
- Introduce an EntityIdHolder interface (somewhere outside Repo), make EntityContent implement it, and make EntityChange refer only to that interface rather than EntityContent.
- Split EntityChange into two parts: the ones that are expected to be called from Repo and populate the change, and the ones that are expected to be called from Client and consume it.
- Add an EntityId parameter to EntityChange::setRevisionInfo() and make the callers get the entity ID from the content (the callers are in Repo).
I still like the concept behind #2, but #3 is so easy to implement that I couldn’t resist it. Patch incoming.
Just an interesting note here that might impact what is being done.
Content objects, and thus EntityContent objects, are important for ENtity retrieval, and thus should perhaps be alongside whatever code is needed for data retrieval withing Wikibase (Of course this depends on how the client repo dependency continues to evolve.
To get content of an entity you start with a revision, which has slots, which have content.
It appears that our current legacy code goes around this, but any sort of new entity lookup based on the new services in core would likely need content to be accessible for clients that do direct DB access.
(prototype example at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/605333/)