Last modified: 2009-01-14 23:26:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T19028, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17028 - Add IBM DB2 support to MediaWiki database modules
Add IBM DB2 support to MediaWiki database modules
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Leons Petrazickis
http://lists.wikimedia.org/pipermail/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-14 22:09 UTC by Leons Petrazickis
Modified: 2009-01-14 23:26 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Diffs and new files for the IBM DB2 support in (22.22 KB, application/x-gzip)
2009-01-14 22:43 UTC, Leons Petrazickis
Details

Description Leons Petrazickis 2009-01-14 22:09:48 UTC
There is a ready and tested patch. I am committing and then maintaining it as leonsp.
Comment 1 Leons Petrazickis 2009-01-14 22:43:08 UTC
Created attachment 5678 [details]
Diffs and new files for the IBM DB2 support in

Couldn't generate one big diff, so generated diffs for each file and put into an analogous directory structure. New files are interspersed with the diffs.
Comment 2 Leons Petrazickis 2009-01-14 22:43:42 UTC
Committed as r45755.

(bug 17028) Added support for IBM DB2 database. config/index.php has new interface elements that only show up if PHP has ibm_db2 module enabled. AutoLoader knows about the new DB2 classes. GlobalFunctions has a new constant for DB2 time format. Revision class fixed slightly. Also includes new PHP files containing the Database and Search API implementations for IBM DB2.

There was more discussion at this URL:
http://lists.wikimedia.org/pipermail/wikitech-l/2008-December/040683.html

There needs to be a follow-up bug to address the bits of administrative pages that use the non-cross-database LIMIT statement explicitly instead of calling the Database API limitResult() function.
Comment 3 Roan Kattouw 2009-01-14 22:47:28 UTC
(In reply to comment #2)
> There needs to be a follow-up bug to address the bits of administrative pages
> that use the non-cross-database LIMIT statement explicitly instead of calling
> the Database API limitResult() function.
> 

You mean IBM DB2 doesn't support LIMIT? I thought LIMIT was supposed to be a standard SQL statement?
Comment 4 Sam Reed (reedy) 2009-01-14 22:50:40 UTC
MS's SQL Server doesnt' have it in 2000/2005.. Not sure about 2008..
Comment 5 Leons Petrazickis 2009-01-14 22:59:24 UTC
LIMIT isn't standard. DB2 has a FETCH FIRST 10 ROWS ONLY statement. SQL Server has a SELECT TOP 10 statement. Oracle has nothing built-in, but LIMIT can be approximated using nested selects and a row number function in the inner one.

The MediaWiki database API has a limitResult($sql, $limit, $offset) function that works around most of these issues, but only if it's used.:-)
Comment 6 Roan Kattouw 2009-01-14 23:01:43 UTC
(In reply to comment #5)
> LIMIT isn't standard. DB2 has a FETCH FIRST 10 ROWS ONLY statement. SQL Server
> has a SELECT TOP 10 statement. Oracle has nothing built-in, but LIMIT can be
> approximated using nested selects and a row number function in the inner one.
> 
> The MediaWiki database API has a limitResult($sql, $limit, $offset) function
> that works around most of these issues, but only if it's used.:-)
> 

Can't you just rewrite LIMIT 50 to FETCH FIRST 50 ROWS ONLY transparently, like DatabaseMySQL rewrites USE INDEX(foo) to FORCE INDEX(foo) ?
Comment 7 Leons Petrazickis 2009-01-14 23:26:00 UTC
That's already being done. I'm not referring to doQuery() $options. Those are handled transparently.

The problem is the slew of Special pages that build a SQL statement by hand and then call the raw query() method. If you were to pass a USE INDEX clause to those, it would crash MySQL too. They use hard-coded LIMIT stuff.

In the long run, those pages will all be migrated to use the Database API. In the short run, they can be fixed by just using the limitResult() bit of the Database API.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links