Hi Bernhard,
it's very arguable what exactly is meant by "more professional". Generally speaking, speed is MySQL's forte, and is also what MediaWiki has a great need for (particularly with Wikipedia). The magazine articles you've read were probably referring to some of the more "enterprise" features (MySQL for a long time did not support transactions, and replication was dubious at best) which MediaWiki doesn't really need. I don't personally think there is much benefit in letting the code use Postgres, but if you're willing to put in the effort - hey, great, send a patch.
As for the MediaWiki table structure, while I'm sure we can help with problems you might encounter, it might be easier for you to install, temporarily, MySQL on one of your machines. MySQL binaries are available for a slew of operating systems and architectures, so it shouldn't take very long.
Cheers, Ivan
Bernhard.Naegele@t-online.de 03/27/04 12:02 PM >>>
[...] In every article about Open Databases I read, that Postgres is a more professional database than MySQL, so I wonder that there is no interrest in suporting also Postgresql, or is there also interrest?
However, I have a running Postgres database and I want to run also a Wiki Wiki. The question for me is now if I should take PHPWiki which has Postgres support or if I should spend some time in enhancing MediaWiki. At the moment, it seams that MediaWiki has more interesting features than PHPWiki....... So my first question: Was there a demand for Postgres in the past? Second: Is there anyone who can suport me if I have some question about MySQL (table-structure of MediaWiki) support of MediaWiki? I don't want to install also MySQL on some of my computers...... Best regards, Bernhard
_______________________________________________ Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Ivan Krstic wrote:
Hi Bernhard,
it's very arguable what exactly is meant by "more professional". Generally speaking, speed is MySQL's forte, and is also what MediaWiki has a great need for (particularly with Wikipedia). The magazine articles you've read were probably referring to some of the more "enterprise" features (MySQL for a long time did not support transactions, and replication was dubious at best) which MediaWiki doesn't really need. I don't personally think there is much benefit in letting the code use Postgres, but if you're willing to put in the effort - hey, great, send a patch.
As for the MediaWiki table structure, while I'm sure we can help with problems you might encounter, it might be easier for you to install, temporarily, MySQL on one of your machines. MySQL binaries are available for a slew of operating systems and architectures, so it shouldn't take very long.
Cheers, Ivan
I'm really pleased that Bernhard has stepped forward to offer to work on this. Thank you, Bernhard!
I think the question of which database is best for Wikipedia is very much an open question; it's entirely possible that a database that is faster under a simple load because of simple uncomplicated code may be slower under a complex load, because of a lack of code to resolve complex concurrency issues.
I don't know if that's true -- what I do know is that it would be very useful to be able to run MediaWiki on either, as this will * increase choice, particularly in the future * reduce dependence on the SQL idioms of any given DBMS: standards are good! * enable benchmarking to see which database is most suitable for our current and predicted future loads.
Certainly, in the near future, the Wikipedia DB will have "enterprise class" needs for resilience and scalability. In particular, thorough support for replication and snapshotting are likely to be important.
-- Neil
Neil Harris wrote:
I'm really pleased that Bernhard has stepped forward to offer to work on this. Thank you, Bernhard!
Yes, this is a very good thing indeed!
- reduce dependence on the SQL idioms of any given DBMS: standards are
good!
I suggest putting *all* current queries into a new MySQL PHP class. A new database can then be added by "simply" rewriting that class.
Magnus
"MM" == Magnus Manske magnus.manske@web.de writes:
MM> I suggest putting *all* current queries into a new MySQL PHP MM> class. A new database can then be added by "simply" rewriting MM> that class.
Why not use an existing database abstraction layer, like ADOdb?
Or ODBC (yes, it works for Linux), or SQLrelay? I dunno if it makes sense to roll our own.
~ESP
On Mar 28, 2004, at 14:06, Evan Prodromou wrote:
"MM" == Magnus Manske magnus.manske@web.de writes:
MM> I suggest putting *all* current queries into a new MySQL PHP MM> class. A new database can then be added by "simply" rewriting MM> that class.Why not use an existing database abstraction layer, like ADOdb?
I believe what Magnus is suggesting is abstracting the *queries*, not the database's API, which we already do. For instance, where we now use our existing roll-your-own database API layer to do something like:
$ns = $title->getNamespace(); $t = wfStrencode( $title->getDBkey() ); $id = wfQuery( "SELECT cur_id FROM cur WHERE cur_namespace=$ns AND cur_title='$t'", DB_READ );
we would do something like this:
$id = $wgDatabase->getArticleId( $title );
where the database class would contain the actual SQL query. I'm not sure to what extent this is necessary or desirable; my preference would be to consider SQL to be our query abstraction layer already, and just try harder than we do now to have well-factored code that keeps queries contained in the classes that deal with that particular type of data. Even now we do:
$id = $title->getArticleId();
and keep the SQL for it tucked away in the Title object (or actually in LinkCache).
For the most part, database-specific SQL should only be happening in install and upgrade phases, or with more exotic features like full-text search.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
On Mar 28, 2004, at 14:06, Evan Prodromou wrote:
Why not use an existing database abstraction layer, like ADOdb?
I believe what Magnus is suggesting is abstracting the *queries*, not the database's API
Yup.
, which we already do.
<snip>
my preference would be to consider SQL to be our query abstraction layer already, and just try harder than we do now to have well-factored code that keeps queries contained in the classes that deal with that particular type of data.
Putting all the queries into a single PHP class would have some advantages, though. Just think of all the special pages; should we really carry MySQL, Postgres and who-knows-what in every special page class?
Universal SQL would be a fine thing, but isn't the point of trying another database to get more performance? That probably means to code using the advantages of a specific database, while keeping clear of the database-specific "problem zones".
Also, two database could be compared much better if we could just throw a switch ( $db=new WikiMySQL; / $db=new WikiPostGres; ).
Even now we do:
$id = $title->getArticleId();
and keep the SQL for it tucked away in the Title object (or actually in LinkCache).
So, the method in Title is basically a wrapper for the method in LinkCache. Why can't the latter (basically) be a wrapper for the method in the database-specific class?
Magnus
Hello, there is also one scenario for which it can be also interesting to have support to some other databases --> this is when a WikiWiki is "only" part of a hole system, where a different database is used for other purpose. It is easier for an administrator to have only one database running, which fits to the most important application...... Best regards, Bernhard
Am Sonntag, 28. März 2004 00:06 schrieb Neil Harris:
Ivan Krstic wrote:
Hi Bernhard,
it's very arguable what exactly is meant by "more professional". Generally speaking, speed is MySQL's forte, and is also what MediaWiki has a great need for (particularly with Wikipedia). The magazine articles you've read were probably referring to some of the more "enterprise" features (MySQL for a long time did not support transactions, and replication was dubious at best) which MediaWiki doesn't really need. I don't personally think there is much benefit in letting the code use Postgres, but if you're willing to put in the effort - hey, great, send a patch.
As for the MediaWiki table structure, while I'm sure we can help with problems you might encounter, it might be easier for you to install, temporarily, MySQL on one of your machines. MySQL binaries are available for a slew of operating systems and architectures, so it shouldn't take very long.
Cheers, Ivan
I'm really pleased that Bernhard has stepped forward to offer to work on this. Thank you, Bernhard!
I think the question of which database is best for Wikipedia is very much an open question; it's entirely possible that a database that is faster under a simple load because of simple uncomplicated code may be slower under a complex load, because of a lack of code to resolve complex concurrency issues.
I don't know if that's true -- what I do know is that it would be very useful to be able to run MediaWiki on either, as this will
- increase choice, particularly in the future
- reduce dependence on the SQL idioms of any given DBMS: standards are
good! * enable benchmarking to see which database is most suitable for our current and predicted future loads.
Certainly, in the near future, the Wikipedia DB will have "enterprise class" needs for resilience and scalability. In particular, thorough support for replication and snapshotting are likely to be important.
-- Neil
Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Hello, I tried to install Mediawiki together with MySQL (even if I want to port Mediawiki to PostgreSQL). I took the MySQL-4.0.18, apache-1.3.28 and php-4.2.3 source. For Mediawiki installation I took the index.php script in the wiki/config/ directory (web-based installation). This all went well until the first start of the index.php script in the main directory. Here I have now some problems with connecting to the database. The following message occurs, when I load the index.php file: ************Start error message *********************** Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource in /raid00/httpd/htdocs/mediawiki/includes/Database.php on line 196
Warning: Cannot add header information - headers already sent by (output started at /raid00/httpd/htdocs/mediawiki/includes/Database.php:196) in / raid00/httpd/htdocs/mediawiki/includes/Database.php on line 415
Warning: Cannot add header information - headers already sent by (output started at /raid00/httpd/htdocs/mediawiki/includes/Database.php:196) in / raid00/httpd/htdocs/mediawiki/includes/Database.php on line 450
Warning: Cannot add header information - headers already sent by (output started at /raid00/httpd/htdocs/mediawiki/includes/Database.php:196) in / raid00/httpd/htdocs/mediawiki/includes/Database.php on line 451 Sorry! The wiki is experiencing some technical difficulties, and cannot contact the database server. *************End Error Message****************
Has anyone an idea, what the problem for this Error-Messages could be? I wouldn's spent to much time in finding problems with MySQL. My goal is to come up with Postgres as fast as possible...... Best regards, Bernhard
Am Samstag, 27. März 2004 21:01 schrieb Ivan Krstic:
Hi Bernhard,
it's very arguable what exactly is meant by "more professional". Generally speaking, speed is MySQL's forte, and is also what MediaWiki has a great need for (particularly with Wikipedia). The magazine articles you've read were probably referring to some of the more "enterprise" features (MySQL for a long time did not support transactions, and replication was dubious at best) which MediaWiki doesn't really need. I don't personally think there is much benefit in letting the code use Postgres, but if you're willing to put in the effort - hey, great, send a patch.
As for the MediaWiki table structure, while I'm sure we can help with problems you might encounter, it might be easier for you to install, temporarily, MySQL on one of your machines. MySQL binaries are available for a slew of operating systems and architectures, so it shouldn't take very long.
Cheers, Ivan
Bernhard.Naegele@t-online.de 03/27/04 12:02 PM >>>
[...] In every article about Open Databases I read, that Postgres is a more professional database than MySQL, so I wonder that there is no interrest in suporting also Postgresql, or is there also interrest?
However, I have a running Postgres database and I want to run also a Wiki Wiki. The question for me is now if I should take PHPWiki which has Postgres support or if I should spend some time in enhancing MediaWiki. At the moment, it seams that MediaWiki has more interesting features than PHPWiki....... So my first question: Was there a demand for Postgres in the past? Second: Is there anyone who can suport me if I have some question about MySQL (table-structure of MediaWiki) support of MediaWiki? I don't want to install also MySQL on some of my computers...... Best regards, Bernhard
Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On Apr 10, 2004, at 01:56, Bernhard Naegele wrote:
The following message occurs, when I load the index.php file: ************Start error message *********************** Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource in /raid00/httpd/htdocs/mediawiki/includes/Database.php on line 196
Looks like a failure to connect to the database. IIRC there was a bug in the install script that failed to set up the user account at least under some circumstances... Change lines 196-197 in Database.php to:
function lastErrno() { return mysql_errno(); } function lastError() { return mysql_error(); }
(remove the "$this->mConn" from each line). It ought now to give out a more useful error message.
-- brion vibber (brion @ pobox.com)
Hello Brion, sorry, but the only message which is now comming out is:
Sorry! The wiki is experiencing some technical difficulties, and cannot contact the database server.
Have you any hint for me? Best regards, Bernhard
Am Samstag, 10. April 2004 11:54 schrieb Brion Vibber:
On Apr 10, 2004, at 01:56, Bernhard Naegele wrote:
The following message occurs, when I load the index.php file: ************Start error message *********************** Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource in /raid00/httpd/htdocs/mediawiki/includes/Database.php on line 196
Looks like a failure to connect to the database. IIRC there was a bug in the install script that failed to set up the user account at least under some circumstances... Change lines 196-197 in Database.php to:
function lastErrno() { return mysql_errno(); } function lastError() { return mysql_error(); }
(remove the "$this->mConn" from each line). It ought now to give out a more useful error message.
-- brion vibber (brion @ pobox.com)
Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On Apr 10, 2004, at 04:24, Bernhard Naegele wrote:
Sorry! The wiki is experiencing some technical difficulties, and cannot contact the database server.
Have you any hint for me?
Check that the user permissions were granted. Can you manually connect to the database using the assigned username and password? If not, modify a copy of maintenance/users.sql and apply it as root.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org