Leons Petrazickis wrote:
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
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