Leons Petrazickis wrote:
On Tue, Nov 18, 2008 at 3:22 AM, Tim Starling
<tstarling(a)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
Excellent. Specify your preferred username.
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
Yes, sounds good.
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.
Indeed.
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.
Yes. We already have some degree of abstraction in our SQL files in the
form of comments like /*$wgDBTableOptions*/. I'm not sure what the best
way to do it is, but here are my ideas:
1. Extend that comments system
2. Introduce an SQL-like language that can be translated to real SQL
3. Introduce an entirely new data definition language, say XML-based
The idea of 1 is to maintain backwards compatibility for scripts that want
to feed SQL files directly into a MySQL database. But it's the least
flexible because it would get really ugly really fast as you add more
features.
2 is nice in that the schema files would be easy to read and write.
Scripts that previously sourced SQL can now just pipe through the
translator instead. We could invent data types like "mwtimestamp" which
translates to "binary(14)" for MySQL and "timestamptz" for PostgreSQL.
The
drawback is that the parser could be complex, especially if it has to deal
with features like foreign key constraints and trigger functions (both of
which are used in the current PostgreSQL schema).
3 could be very simple to implement, since you could just have
DBMS-dependent cases written out in full. But the resulting files might be
difficult to update.
It would probably be worthwhile to do a survey of existing open-source
solutions.
-- Tim Starling