On Tue, Nov 18, 2008 at 3:22 AM, Tim Starling <tstarling(a)wikimedia.org> wrote:
Leons Petrazickis wrote:
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:
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
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
I'm doing some work on the installer frontend, but
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.