Page MenuHomePhabricator

Consider splitting the IDatabase interface
Open, Needs TriagePublic

Description

Currently the IDatabase interface deals with all possible database interaction.
The interface currently has ~130 methods, with new ones appearing every week or so.

Many bits of code that use our database classes really don't care about 90% of these methods.
Could we put some thought into potentially splitting the interface?

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 22 2018, 9:16 AM
aaron added a comment.Mar 22 2018, 3:48 PM

It's kind of hard to do this in practice, give the use of load balancers and so on. Some stuff can be removed, deprecated, or moved to IMaintainableDatabase though.

Change 421327 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] rdbms: IDatabase interface cleanups

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

Change 421327 merged by jenkins-bot:
[mediawiki/core@master] rdbms: IDatabase interface cleanups

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

Krinkle added a subscriber: Krinkle.

I see two good opportunities in IDatabase for splitting:

  1. Separate logic for schema maintenance from logic for application queries.

This is the separation layer we've implemented with IMaintainableDatabase, which we use for queries performed by the installer, db-updater, and some maintenance scripts. In other words, the showing, creating, altering and dropping of databases, tables, indexes, and related responsibilities (such as reading patch files).

  1. Separate logic for database interaction from logic for building sql text.

This is a proposal for a possible next refactor, which would reduce IDatabase to only the state management of the connection and the logic needed to send and interpret queries.

The stateless logic for building sql text (e.g. "query builder") could be separated. The main reason I'm proposing this is so that we could group together all the stateless utility methods for rdbms-backend specific SQL text manipulation. As well as in context of deprecating raw SQL chunks in queries (see T210206).