wb_terms is logically an isolated table from all other mediawiki or wikibase functionality.
Once we got to the point of refactoring our code to interact with the new schema, we thought we might as well try to decouple that logic into a separate library.
Since that library will have to interact with a database, and to avoid coupling it back to things that it does not need to depend on really, we want to investigate whether we can as well decouple on DB level interaction.
Doctrine DBAL is our choice for the benefits listed below.
This task is negatively concluded if any of the following fail:
- (POC) we have experimented with the decoupled solution, using Doctrine DBAL, and tested it in isolation. [ Github Repo and related to that T220155]
- (RFC) we have informed, collected feedback and got approval on using a DBAL other than MW one in production from all concerned parties at WMF.
- (MVP) we have integrated a minimal production-ready implementation (limited to Property Terms) of the decoupled solution into Wikibase and tested it on beta and test environments. (follow on T219121)
If the task concludes positively, we go ahead and continue with the decoupled Doctrine DBAL based solution.
If the task concludes negatively, we continue with MW DBAL based solution.
Benefits of introducing Doctrine DBAL
Apart from the obvious improvements on the architectural level that we gain from building a decoupled solution, going with that to DBAL level and use Doctrine DBAL instead of MW one has the following benefits on the long term.
- Doctrine is quite popular project, and many developers have worked or would be more willing to learn it than any custom homemade framework. This reduces both learning curve steepness and knowledge friction for new comers and volunteers.
- Doctrine is a well design, well maintained and well documented open source DBAL solution.
- Doctrine already supports multiple platforms, including but not limited to the ones supported by MW.
- Much faster and fully isolated tests (~50 ms to run all tests)
Possible drawbacks of not using MW DBAL
- extra maintenance to support specific and significant functionality implemented in MW DBAL? (please list if you know any)
- <specific significant functionality we cannot live without #1>