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 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)