Database abstraction layer - Wikitech-l - lists.wikimedia.org

List overview All Threads
Download

Database abstraction layer

Website to block

taking forever for MediaZilla...

Evan Prodromou

29 Nov 2004 29 Nov '04

2:38 p.m.

Why did we write our own database abstraction layer when there's one already in PEAR? ~ESP -- Evan Prodromou <evan(a)wikitravel.org>

Attachments:

signature.asc (application/pgp-signature — 189 bytes)

Reply

Show replies by thread

Brion Vibber

29 Nov 29 Nov

5:09 p.m.

On Nov 29, 2004, at 5:38 AM, Evan Prodromou wrote:

Why did we write our own database abstraction layer when there's one already in PEAR?

Most likely, the people writing it at the time weren't aware of the existence of PEAR. IIRC PHP didn't ship with the base PEAR packages until 4.3.0, which was released in December 2002, well over a year after Magnus's development began, and nearly six months after Lee's phase 3 overhaul went live on Wikipedia. -- brion vibber (brion @ pobox.com)

Reply

Tim Starling

11:11 p.m.

Evan Prodromou wrote:

Why did we write our own database abstraction layer when there's one already in PEAR?

Database abstraction is only a small part of what Database.php does. PEAR has a couple of query-building functions -- a quoting function, for instance. Our query-building functions are much better. Maybe we should contribute what we have done to PEAR at some stage. An interface to PEAR's DB module, or PHP's native dbx module, was in fact the next Database subclass I wanted to write. It would be handy for non-Wikimedia users. You should think of Database.php as a query-building module rather than a DB abstraction layer. -- Tim Starling

Reply

Evan Prodromou

30 Nov 30 Nov

9:03 p.m.

On Tue, 2004-30-11 at 09:11 +1100, Tim Starling wrote:

You should think of Database.php as a query-building module rather than a DB abstraction layer.

But it's both. I guess I'm mainly worried that this huge change was made without considering other options. There wasn't any discussion on this list that I can find, and the change isn't documented on meta, AFAICT. Publishing design decisions can be a good way to avoid second-guessing by people like me after the code is written. ~ESP -- Evan Prodromou <evan(a)wikitravel.org>

Reply

Tim Starling

1 Dec 1 Dec

3:24 a.m.

Evan Prodromou wrote:

I guess I'm mainly worried that this huge change was made without considering other options. There wasn't any discussion on this list that I can find, and the change isn't documented on meta, AFAICT. Publishing design decisions can be a good way to avoid second-guessing by people like me after the code is written.

What huge change? Like Brion said, DatabaseFunctions.php has existed since the dawn of time. I switched it to OOP to support multiple connections, I probably announced that in a post about slave servers and load balancing. Then Domas implemented PostgreSQL support as a subclass. Domas' work doesn't preclude the use of a DB abstraction layer, in fact his work in identifying the use of MySQL-specific features would be invaluable should we attempt such a thing. As far as I'm concerned, DB abstraction is a courtesy to low-traffic non-Wikimedia users. The queries we use, and the schema, should be optimised for MySQL. My focus has been on emulation of MySQL features, not replacement by standard SQL in the bulk of the codebase. INSERT IGNORE is the best example of this. -- Tim Starling

Reply

Evan Prodromou

7:16 a.m.

On Wed, 2004-01-12 at 13:24 +1100, Tim Starling wrote:

I guess I'm mainly worried that this huge change was made without considering other options.

What huge change?

Replacing all the SQL strings in the code with function calls into a much-expanded database object.

As far as I'm concerned, DB abstraction is a courtesy to low-traffic non-Wikimedia users.

I'm not speaking as a non-Wikimedia user; I'm speaking as a member of the MediaWiki development team we're both on. I'm just trying to get across the point that even the World's Greatest Programmer can benefit from soliciting the ideas of others in a forum such as wikitech-l. It only takes a few minutes, helps the developer focus their own thoughts, and could avoid a lot of work for the entire development team writing, testing and debugging functionality readily available in an Open Source library. We all benefit from a better product that comes from sharing our ideas. And if you fix your ideas in writing, you don't get dumb questions later. Or, y'know, fewer dumb questions. Anyways: sorry if I touched a nerve. If it helps, I think this is a real nice piece of code, and it really cleans up the rest of the codebase. ~ESP -- Evan Prodromou <evan(a)wikitravel.org>

Reply

Tim Starling

7:56 a.m.

Evan Prodromou wrote:

On Wed, 2004-01-12 at 13:24 +1100, Tim Starling wrote:

I guess I'm mainly worried that this huge change was made without considering other options.

What huge change?

Replacing all the SQL strings in the code with function calls into a much-expanded database object.

I discussed it on IRC, with Brion and anyone else who was around. Replacing SQL strings with function calls was done for these reasons: * Safer quoting, avoidance of SQL injection attacks * Easier table prefix support * Simpler interface with PHP data structures, like wfGetSQL() before it * DB abstraction, specifically: ** Filtering or emulation of unsupported options to queries such as DELAYED ** Emulation of MySQL-specific queries such as REPLACE ** Table name quoting If you want to be in on these decisions you should hang around on #mediawiki more. Discussing things by email is tedious and slow. -- Tim Starling

Reply

Evan Prodromou

8:21 a.m.

On Wed, 2004-01-12 at 17:56 +1100, Tim Starling wrote:

If you want to be in on these decisions you should hang around on #mediawiki more.

My point isn't that I want to be in on the decisions. My point is that I want us as a development group to make better decisions, and I want us as a group to communicate those decisions well to present and future members of this development team. I know from experience that if we do this, we will make better software, and our job will be easier, to boot.

Discussing things by email is tedious and slow.

Discussing things on IRC is ephemeral and the discussions are hard to point to later. ~ESP -- Evan Prodromou <evan(a)wikitravel.org>

Reply

The Cunctator

3:46 p.m.

New subject: Account lockout

My account has a guessable password and some idiot has used my account for some low-grade idiocy (blocked JoeM and put some dumb text on the "Xero" page, both reverted quickly) and changed the password. I didn't set the email to the account. Could someone change the password/lock the account and set the email to "cunctator(a)kband.com" so I can reset the password? Thx.

Reply

Tim Starling

11:43 p.m.

New subject: Account lockout

The Cunctator wrote:

My account has a guessable password and some idiot has used my account for some low-grade idiocy (blocked JoeM and put some dumb text on the "Xero" page, both reverted quickly) and changed the password. I didn't set the email to the account. Could someone change the password/lock the account and set the email to "cunctator(a)kband.com" so I can reset the password?

This is done. -- Tim Starling

Reply

7085

days inactive

7087

days old

wikitech-l@lists.wikimedia.org

Manage subscription

9 comments

4 participants

tags (0)

participants (4)

Brion Vibber
Evan Prodromou
The Cunctator
Tim Starling