Hello,
I would like to know if there is any work to have DB2 supported by Mediawiki. Also if there isn't, if I could start a project to create this support, I mean if this is possible and/or desirable.
Thanks and best regards, Esthon Medeiros.
On Mon, Jun 23, 2008 at 8:37 PM, Esthon Medeiros esthon@terra.com.br wrote:
I would like to know if there is any work to have DB2 supported by Mediawiki. Also if there isn't, if I could start a project to create this support, I mean if this is possible and/or desirable.
If you want support, submit a patch. Look in Database.php and various subclasses, like DatabasePostgres.php. These are in includes/db/ in current trunk. Write up a DatabaseDB2.php and submit it on Bugzilla or somewhere. Changes also might be needed to the installer script to give it as an installation option.
Simetrical wrote:
On Mon, Jun 23, 2008 at 8:37 PM, Esthon Medeiros esthon@terra.com.br wrote:
I would like to know if there is any work to have DB2 supported by Mediawiki. Also if there isn't, if I could start a project to create this support, I mean if this is possible and/or desirable.
If you want support, submit a patch. Look in Database.php and various subclasses, like DatabasePostgres.php. These are in includes/db/ in current trunk. Write up a DatabaseDB2.php and submit it on Bugzilla or somewhere. Changes also might be needed to the installer script to give it as an installation option.
Indeed, good luck implementing it. :)
But I will warn you -- it'll save you a *lot* of trouble to just install a copy of MySQL. It'll actually *work* instead of spending months discovering new compatibility problems every time you try a new feature or upgrade.
-- brion
Brion Vibber escreveu:
Simetrical wrote:
On Mon, Jun 23, 2008 at 8:37 PM, Esthon Medeiros esthon@terra.com.br wrote:
I would like to know if there is any work to have DB2 supported by Mediawiki. Also if there isn't, if I could start a project to create this support, I mean if this is possible and/or desirable.
If you want support, submit a patch. Look in Database.php and various subclasses, like DatabasePostgres.php. These are in includes/db/ in current trunk. Write up a DatabaseDB2.php and submit it on Bugzilla or somewhere. Changes also might be needed to the installer script to give it as an installation option.
Indeed, good luck implementing it. :)
But I will warn you -- it'll save you a *lot* of trouble to just install a copy of MySQL. It'll actually *work* instead of spending months discovering new compatibility problems every time you try a new feature or upgrade.
-- brion
Hi Brion,
you're right, if it was only for my use and I already installed it with mysql and it was very fast to install and begin to use, excellent application. But, my suggestion is to create more compatibility for the product, I can see in this table http://en.wikipedia.org/wiki/Comparison_of_wiki_software that few have DB2 support, so if it is not very complex I would like to work with it.
If more people like the idea and wish to join me in this effort please let me know.
Esthon Medeiros.
On Tue, Jun 24, 2008 at 10:20 AM, Esthon Medeiros esthon@terra.com.br wrote:
Brion Vibber escreveu:
Simetrical wrote:
On Mon, Jun 23, 2008 at 8:37 PM, Esthon Medeiros esthon@terra.com.br wrote:
I would like to know if there is any work to have DB2 supported by Mediawiki. Also if there isn't, if I could start a project to create this support, I mean if this is possible and/or desirable.
If you want support, submit a patch. Look in Database.php and various subclasses, like DatabasePostgres.php. These are in includes/db/ in current trunk. Write up a DatabaseDB2.php and submit it on Bugzilla or somewhere. Changes also might be needed to the installer script to give it as an installation option.
Indeed, good luck implementing it. :)
But I will warn you -- it'll save you a *lot* of trouble to just install a copy of MySQL. It'll actually *work* instead of spending months discovering new compatibility problems every time you try a new feature or upgrade.
-- brion
Hi Brion,
you're right, if it was only for my use and I already installed it with mysql and it was very fast to install and begin to use, excellent application. But, my suggestion is to create more compatibility for the product, I can see in this table http://en.wikipedia.org/wiki/Comparison_of_wiki_software that few have DB2 support, so if it is not very complex I would like to work with it.
If more people like the idea and wish to join me in this effort please let me know.
Esthon Medeiros.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I know Aran was working on a MSSQL class recently. Might be worth your time to ask him what issues he's hit/overcome while trying to implement that.
-Chad
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. Brion -- if you're still following this thread, tell me what it takes to get my stuff rolled in.
On Tue, Jun 24, 2008 at 9:27 AM, Chad innocentkiller@gmail.com wrote:
On Tue, Jun 24, 2008 at 10:20 AM, Esthon Medeiros esthon@terra.com.br wrote:
Brion Vibber escreveu:
Simetrical wrote:
On Mon, Jun 23, 2008 at 8:37 PM, Esthon Medeiros esthon@terra.com.br
wrote:
I would like to know if there is any work to have DB2 supported by
Mediawiki.
Also if there isn't, if I could start a project to create this
support, I mean
if this is possible and/or desirable.
If you want support, submit a patch. Look in Database.php and various subclasses, like DatabasePostgres.php. These are in includes/db/ in current trunk. Write up a DatabaseDB2.php and submit it on Bugzilla or somewhere. Changes also might be needed to the installer script to give it as an installation option.
Indeed, good luck implementing it. :)
But I will warn you -- it'll save you a *lot* of trouble to just install a copy of MySQL. It'll actually *work* instead of spending months discovering new compatibility problems every time you try a new feature or upgrade.
-- brion
Hi Brion,
you're right, if it was only for my use and I already installed it with mysql and it was very fast to install and begin to use, excellent application. But, my suggestion is to create more compatibility for the product, I can see in this table http://en.wikipedia.org/wiki/Comparison_of_wiki_software that few have DB2 support, so if it is not very complex I would like to work with it.
If more people like the idea and wish to join me in this effort please let me know.
Esthon Medeiros.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I know Aran was working on a MSSQL class recently. Might be worth your time to ask him what issues he's hit/overcome while trying to implement that.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
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
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
On Tue, Jun 24, 2008 at 4:53 PM, Aran aran@organicdesign.co.nz wrote:
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.
That might be best fixed where the queries are used, then. That syntax is rather opaque anyway.
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.
This is fixable at the abstraction layer, or should be. Look at what PostgreSQL does: they don't submit a NULL, they insert some function call or other.
Esthon Medeiros a écrit :
you're right, if it was only for my use and I already installed it with mysql and it was very fast to install and begin to use, excellent application. But, my suggestion is to create more compatibility for the product, I can see in this table http://en.wikipedia.org/wiki/Comparison_of_wiki_software that few have DB2 support, so if it is not very complex I would like to work with it.
Nowaday, webapps use either Postgre or MySQL because they are fast, reliable enough. People tend to start using Sqlite too as it is even lighter and need close to no configuration. When using them with PHP, you are just using an open source environment that also comes with Apache and rarely offer any proprietary database format with it.
Some people implemented Oracle and MsSQL support because they already use those in their company. This way they will get support from their usual DBA, handle back up and use the same support contract.
As for DB2, the last time I heard about it, it was clearly not for a webapp. It was used on IBM z/OS which run on the IBM Mainframe. The kind of "servers" which have decade uptime and hold your bank account (and other interesting things).
To conclude, probably nobody is going to use MediaWiki with a DB2 backend. But you can still implements it as an exercice :o)
cheers,
Ashar Voultoiz wrote:
As for DB2, the last time I heard about it, it was clearly not for a webapp. It was used on IBM z/OS which run on the IBM Mainframe. The kind of "servers" which have decade uptime and hold your bank account (and other interesting things).
I've developed DB2 apps on Windows platforms long ago. It's been a multi-platform product since way back when, so I don't know where you got the idea that DB2 is a mainframe-only product. There are versions for Windows, Linux, Unix and other OSes.
I could see a number of companies wanting to use DB2 just as others would want to use MS SQL Server, Oracle or other DB products.
Mike
Michael Daly escreveu:
Ashar Voultoiz wrote:
As for DB2, the last time I heard about it, it was clearly not for a webapp. It was used on IBM z/OS which run on the IBM Mainframe. The kind of "servers" which have decade uptime and hold your bank account (and other interesting things).
I've developed DB2 apps on Windows platforms long ago. It's been a multi-platform product since way back when, so I don't know where you got the idea that DB2 is a mainframe-only product. There are versions for Windows, Linux, Unix and other OSes.
I could see a number of companies wanting to use DB2 just as others would want to use MS SQL Server, Oracle or other DB products.
Mike
Yes, DB2 is a multi-platform product. Also, there is a free version you can download for your personal use. It is a robust database product running in Unix or Linux (including Linux in Mainframe) and it is much more robust and reliable if running in a z/OS. Today mainframes are running web sites supporting the very big load peek of transactions that occurs frequently.
I think of an environment where we would have MediaWiki running in a Linux in a mainframe partition connected to a DB2 running in z/OS in another partition at the same mainframe. The connection would be done through the use of a hypersocket (virtual LAN) that in reality transfers memory to memory.
I have no problems with mySQL of Oracle or any other database. I like mySQL very much and use it a lot. But I think, as I told before, that MediaWiki could have more alternatives of choice for database. This could be good for more enterprise use of MediaWiki.
Esthon. (BTW, I work for IBM, but my work here is personal).
Simetrical escreveu:
On Mon, Jun 23, 2008 at 8:37 PM, Esthon Medeiros esthon@terra.com.br wrote:
I would like to know if there is any work to have DB2 supported by Mediawiki. Also if there isn't, if I could start a project to create this support, I mean if this is possible and/or desirable.
If you want support, submit a patch. Look in Database.php and various subclasses, like DatabasePostgres.php. These are in includes/db/ in current trunk. Write up a DatabaseDB2.php and submit it on Bugzilla or somewhere. Changes also might be needed to the installer script to give it as an installation option.
Hi, is this the right path you were talking http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/db/ ?
Esthon.
On Tue, Jun 24, 2008 at 8:37 PM, Esthon Medeiros esthon@terra.com.br wrote:
Simetrical escreveu:
On Mon, Jun 23, 2008 at 8:37 PM, Esthon Medeiros esthon@terra.com.br wrote:
I would like to know if there is any work to have DB2 supported by Mediawiki. Also if there isn't, if I could start a project to create this support, I mean if this is possible and/or desirable.
If you want support, submit a patch. Look in Database.php and various subclasses, like DatabasePostgres.php. These are in includes/db/ in current trunk. Write up a DatabaseDB2.php and submit it on Bugzilla or somewhere. Changes also might be needed to the installer script to give it as an installation option.
Hi, is this the right path you were talking http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/db/ ?
Esthon.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
That's it. Database.php is the default mySQL class. The Database*'s are the other various implementations.
-Chad
wikitech-l@lists.wikimedia.org