On Tue, Nov 18, 2008 at 3:22 AM, Tim Starling tstarling@wikimedia.org wrote:
Leons Petrazickis wrote:
Hello,
I work on the DB2 database server at IBM. In my personal time, I've written a patch to add DB2 support to MediaWiki. It supports most of the MediaWiki Database API with some gaps in searching and admin. I'm involved in launching a site based on the patch and moving another wiki onto it, so the gaps should be plugged in due time.
I don't have commit access. Could someone help get this committed?
Will you continue to maintain it? I wouldn't like to see it committed once and then slowly rot. I think you should get commit access, commit it yourself, and then maintain it into the future.
I do have the time to maintain DB2 support for the foreseeable future. There's a couple sites I'm involved with that would use it, so the long-term interest is there.
What do I need to do to get commit access? My public key is: http://lpetr.org/personal/leo-public.pub
Maintenance of non-MySQL DBMS code has been a problem in the past, we really need someone to refactor the common code to Database, move MySQL-specific code to DatabaseMysql, and generalise the installer and updater. If you're looking for something to do.
That's a fair bit of work. Moving the code wouldn't solve the maintenance issue by itself, though.
Would you make Database an abstract class? That would get us this: - DB-agnostic methods could still be defined in Database - DB-specific methods would have to be defined in any child class - there would be a clear error if a required DB-specific method was not implemented
This would be a definite improvement over the current situation where, say, the Oracle layer could have a missing method, escalate to a MySQL-specific one in Database, and fail with varying degrees of mystery.
I'm doing some work on the installer frontend, but a DBMS-independent schema update system (like updaters.inc) would be orthogonal to that.
Ah, that would be quite useful. If done right, it could also be used for installation in place of the DBMS-specific tables.sql files.
What I am envisioning is an abstraction over Data Definition Language -- create table, alter table, rename column stuff -- that's similar in architecture to the Database classes. There'd be a root class that defines a DB-agnostic interface, and DB-specific child classes that implement vendor-specific things.
This would solve the maintenance headache of having several different database schema definitions -- a separate tables.sql to maintain for MySQL, Postgres, SQLite, etc.
A rework of updaters.inc would be a good start. -- Leons Petrazickis http://lpetr.org/blog/