Talk:Requests for comment/Removing bad database abstractions

Few thoughts...
Legoktm (talk) 12:02, 14 September 2014 (UTC)
 * I'd say we do well at MySQL and SQLite because we're kind of forced to. If MySQL breaks, the WMF will have issues, and it'll get reverted. If you break SQLite jenkins will complain and your change will never get merged in the first place. If jenkins ran postgres tests on every change (37602), I bet we'd break it less often.
 * Schemas not being kept up to date...because the updater is kind of annoying. Doing a schema change properly requires adding a line to every DatabaseUpdater file, and creating a patch file for it, and the person proposing the change probably can't even test it on anything asides from MySQL/SQLite. That shouldn't be necessary IMO. I have no ideas on how to fix it though.
 * We should have a section on Developers/Maintainers for each database backend with a list of maintainers. There's already one for postgres, which is good.
 * I'm bouncing a few ideas around my head to make schema updates more painless, but it removes the ability to apply them outside of the updater since it would be defined in PHP only (e.g. no patch file). I'm pretty sure this is a no-go for the WMF though, so I haven't put any of that down in writing yet. In the meantime, it'd be up to the maintainers to keep their individual DBMS up to date, which requires a lot of time spent testing, and it is simply not feasible to keep checking master for schema updates constantly because of this, because usually the "3rd party DBMS" maintainers aren't being paid to develop mediawiki, and thus have very limited free time. I know this is the case for myself, at any rate. Since the testing process is what takes the most time, and has to be repeated each time I update the schema, it makes far more sense for me to only do the schema updates once at the branch point and simply give the expectation that the db driver is only supported for official releases.
 * Having something listed on Developers/Maintainers is probably a good idea, as it shows if there is a point of contact for any particular db driver, which can then be contacted in the event something is broken with their driver. This I believe may have removed the need for this RFC being filed in the first place, as it could be shown then that pretty much everything has an active maintainer, outside of perhaps Oracle.
 * Chad, you suggested this RFC without providing any sort of alternative for these db drivers to live on. It is impossible right now to install a db driver as an extension, so they must live in core at the moment. If part of this RFC was adding a framework to install 3rd party database drivers for interested parties, I'd actually try to work with you on it with what spare time I have (although I still believe a better option would be to improve our core support so that each db driver doesn't require its own separate set of schema updates).
 * -- Skiz zerz  02:40, 24 September 2014 (UTC)


 * I am very much in favor of an abstracted approach as it would alleviate the majority of my concerns here. I would encourage not doing it in PHP though...store the underlying structure in something more reusable like json, etc. so it could be usable outside of MW more easily (I'm thinking something wmf could use to generate our SQL patches)
 * Decoupling the DB backends from core so heavily could be a part of Library infrastructure for MediaWiki. Abstracting the schema would be a big part of this. ^demon[omg plz] 21:22, 8 October 2014 (UTC)

Postgres
When Postgres support gets broken in SMW or Maps, people complain about it. So there definitly are a non-trivial amount of MediaWiki + Postgres users out there. --Jeroen De Dauw (talk) 15:11, 11 October 2014 (UTC)

Use Doctrine
With the adoption of composer, maybe now would be a good time to use a component like Doctrine which supports schema definitions in YAML.

This would remove the DB abstraction from core and adopt a widely used abstraction layer. Seems like a win, to me. -- ☠ MarkAHershberger ☢ (talk) ☣ 17:38, 13 October 2014 (UTC)