Talk:Requests for comment/Moving database abstractions out of MediaWiki core

Next steps

I think a few more parts of the RfC need to be fleshed out a little bit, specifically:

• How the database abstractions are going to integrate and interact with the installer/updater (autoloading from $IP/db??)
• Which database implementation, if any, stays in MediaWiki core?
• How do schema changes work? Are core developers responsible for maintaining the db implementations?
  • I think mysql and sqlite share code in this area, can we avoid duplication? Should we?

After that, we should schedule an IRC meeting for the RfC (but that probably won't happen until after the dev summit in January) and go from there. Legoktm (talk) 23:53, 15 December 2015 (UTC)

Regarding DB implementations in core, I'd recommend the two we actually support: MySQL and SQLite. That also solves your code duplication question neatly enough. Anomie (talk) 14:16, 18 November 2016 (UTC)

Removing the ability to pass in raw SQL strings

Without development work around unioned queries, this looks like it would impact SpecialRecentChangesLinked and the proposed solution for phab:T149077. There's also a loophole since subqueries exist; without development work to create "safe" subqueries of some sort you'd also affect JobQueueDB, ApiQueryAllUsers, ActiveUsersPager, SpecialWhatLinksHere, and SpecialRedirect. Anomie (talk) 14:13, 18 November 2016 (UTC)

A good wrapper doesn't completely eliminate database dependence

I see the following places in core where we're branching based on DB type:

• JobQueueDB has a special case working around a MySQL limitation in using a subquery in an UPDATE statement.
• ApiQueryAllPages has special casing for the different interpretations of SQL 1992 and 1999 with respect to GROUP BY.
• SqlBagOStuff has to use a separate database connection for MySQL to work right, but needs to reuse the same connection for SQLite. It's broken (see phab:T140338) for PostgreSQL and possibly other databases, BTW, looks like because of a bad attempt to fix phab:T29283.
• WatchedItemQueryService adds an extra, otherwise-useless WHERE condition for MySQL as an "index optimization".

Then there's the MySQL has a bug where it'll filesort instead of using an index on (field1, field2) when the query is something like WHERE field1 = 'constant' ORDER BY field1, field2 (i.e. a field is constant in WHERE and is included in ORDER BY), while using the index correctly on WHERE field1 = 'constant' ORDER BY field2. It's possible that some other DB will only use the index correctly for the former, though, in which case we'd probably need to check for it in ApiQueryLinks, ApiQueryBacklinksprop, LonelyPagesPage, and possibly other places that don't call out MySQL in an adjacent comment. Anomie (talk) 14:53, 18 November 2016 (UTC)