Mark and I are interested in running a one-hour bug triage to discuss, validate & prioritize MediaWiki bugs that affect Postgres, SQL Server, Oracle, SQLite, MariaDB, and other non-MySQL databases. Ideally we'd also come out with a first plan on improving database support. If you can make it tomorrow, the 28th, or Nov. 2nd or Nov. 3rd, please indicate that on this poll. If you can make tomorrow, please additionally feel free to ping Mark and me directly and we'll try to make up for the short notice! :-)
http://www.doodle.com/wrwrixnreh3w8vby
Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation
On Mon, Oct 24, 2011 at 3:04 PM, Brion Vibber brion@wikimedia.org wrote:
Hey all --
I've got a stack of issues discussed during the last couple months' conferences and hackathons to raise, so there may be a few more manifestos on the way. But don't worry, this one will be short!
I had a great chat at the New Orleans hackathon with D J Bauch who's been working on maintaining MediaWiki's MS SQL Server support, and also had a very useful email chat a couple weeks back with Freakalowsky who's put a lot of work into MediaWiki's Oracle support.
Long story short: though traditionally MediaWiki developers have put very little work on our own into maintaining non-MySQL compatibility, there's still lots of folks interested in running on them... AND THEY ACTUALLY MOSTLY WORK!
At this point I think it's a bit crazy of us to keep on marginalizing that code; some folks running their own instances will need or want or prefer (or be forced by office IT) to run on some "funny" database, and we shouldn't stand in their way. More importantly, keeping things working with multiple DB backends helps us to keep our code cleaner, and reduces our own hard dependencies on a particular product line.
There are two main impediments to keeping code working on non-MySQL platforms:
- lazy code breakages -- us MySQL-natives accidentally use MySQL-isms that
break queries on other platforms
- lazy schema updates -- us MySQL-natives add new schema updates into the
system but only implement them for MySQL
The first could often be helped simply by having automated testing run to make sure that relevant code paths get exercised. Often there's just a function that's used, or lazy use of LIMIT/OFFSET, or GROUP BY in a form that other databases are pickier about. Just flagging them from the testing can often be enough to make it easy to fix.
The second is a bit harder, but again testing can help flag that something needs to be updated so it doesn't wait until too late for the next release, or something.
I'd like for everybody who's working on MediaWiki on non-MySQL databases to make sure that the phpunit test suite can run on your favorite platform, so we can see about getting them set up in our regular reports on http://integration.mediawiki.org/ci/
Green bars are your friend! :)
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l