There are some difficulties with getting the current implementation of
MSSQL support to work without adjusting code outside the class.
For example the problems in the special pages DJ Bauch mentioned is due
to the GROUP BY being part of a fully constructed SQL string rather than
a DB::selectJoin method or something instead. The GROUP BY would then be
part of an option array so it could be modified in the MSSQL
implmentation of that method.
Also another issue is that MSSQL doesn't like inserts on auto-increment
rows which are declared as NOT NULL but then are inserted with NULL's.
MySQL ignores the NULL since its an auto-increment row and so not
actually inserted. But MSSQL doesn't like it so it may be good to change
such NULL's to 0 or "" or whatever type is appropriate, or not include
those columns at all in the inserts.
DJ Bauch wrote:
The issue arose because I used the ADOdb Database
Abstraction Library for
PHP and Python (from
adodb.sourceforge.net). Early attempts to use the PHP
mssql connector just resulted in disappointment, particularly in the
handling of BLOBs, if I recall. I have thought about attacking MSSQL again,
just so I can see if I have better luck now that I'm a PHP version or two
ahead of where I was the last time I tried it. Since I already had lots of
experience with ADO, I found the other adapter to be quite easy to use.
I misremembered the frequency of the issue with most of the special pages.
The thing that tends to cause more changes there tends to be the GROUP BY
clauses in the SQL. SQL Server doesn't like GROUP BY 1,2,3... Line 44 in
SpecialWantedcategories.php, for example, I changed from "GROUP BY 1,2,3" to
"GROUP BY cl_to", cl_to being the only column that changes. Similarly, line
38 in SpecialFewestRevisions.php I changed from "GROUP BY 1,2,3" to
"GROUP
BY page_namespace,page_title". I don't think these changes alter the
semantics of the result.
SpecialStatistics.php, however, demonstrates the issue I identified with the
result retrieval mode. In that file, I have at line 58
"$dbr->SetFetchModeAssoc()", followed by the query "$res =
$dbr->select(...", which goes on for several lines -- then at line 75, I
have "$dbr->SetFetchModeNum()" to go back to the default fetch mode. The
issue is that ADO wants the fetch mode set at the time of the query, not at
the time you actually start to retrieve the results of the query. For ADO,
that is too late!
As I said, this only shows up in a few places in the code. For the most
part, Mediawiki retrieves the results using numeric field identifiers.
On Tue, Jun 24, 2008 at 1:05 PM, Brion Vibber <brion(a)wikimedia.org> wrote:
DJ Bauch wrote:
I have had Mediawiki running on Microsoft SQL
Server pretty much without
any
problems for several months now, originally on
SQL Server 2000, but now
on
2005. This week the boss decided it was time to
move it from our
development
box to a production server. The version I'm
running is based on release
1.12, but includes quite a bit from the 1.13 code as well. That includes
several extensions. I'd love to have my stuff rolled in to the shared
source. The only significant change that impacts quite a few of the PHP
sources (primarily the Special... stuff) is that I had to add a couple of
methods to the Database class to switch back and forth between returning
query results in arrays (which works most of the time) and returning
query
results in objects with fields accessed by name.
For performance reasons,
the ADODB class that I used only does one or the other.
It sounds like the best way to handle this would be for fetchObject() /
fetchRow() to translate formats, rather than change all other code.
The current DatabaseMssql.php seems to be using mssql_fetch_object() and
mssql_fetch_array() already; is there any problem with how this works
presently?
-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l