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@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
- 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l