Author: jason.filby
Description:
A database abstraction layer would allow databases besides MySQL (eg. PostgreSQL, Oracle).
There are many db abstraction layers out there, so it would really be a case of rewriting
MySQL specific code to use an abstraction layer once - and then have the portability to all
databases allowed by the abstraction layer.
Version: unspecified
Severity: enhancement
| Unknown Object (Diffusion Commit) | |
| Unknown Object (Diffusion Commit) | |
| Unknown Object (Diffusion Commit) |
We've already got a database abstraction layer (eg, for PostgreSQL support -- see bug 384) though the installer will need
more work.
Are you proposing using a specific external code base (eg, PEAR::DB or similar) instead of our current layer or as a back end
to it?
jason.filby wrote:
I didn't realize that there was an existing database abstraction layer. Even
then, it may be of benefit to use an existing library because 1) you can focus
more on your core software and 2) you may get a wider range of supported databases.
I'm hoping to roll out MediaWiki at work, and while they're willing to accept
MySQL/PostgreSQL, we're really an Oracle shop. So having that option would be
great. Thanks for all the great work on MediaWiki!
mediawiki uses relational databases. the trouble with relational databases is
that for queries you've got to use a language, designed for data retrieval. that
is - SQL. and different databases have different flavours of SQL.
there's no abstraction layer implementing SQL and I do not expect any happening
in near future ;-)
even with dual-database setup having such performance and feature oriented
software showed lots of tricky places in database design and implementation.
it isn't just a DBABSTRACTION->query("SELECT blah from foo where bar=xizzy");
you've got to do data management, and then you've got to stick with the design
of your main database.
jason.filby wrote:
I realize that an abstraction layer isn't a silver bullet, and since WikiMedia
already has one that's great. I'll go for the MySQL installation as that seems
to be the most tested with WikiMedia. I suppose the title of this bug should
really be a request for Oracle support, but I'm sure it won't be that high a
priority.
well, as oracle is not free neither as beer neither as speech, it is really
difficult to put existing developer resources to do oracle support ;-) as every
opensource community, mediawiki team would gladly accept such enhancements.
jason.filby wrote:
Actually Oracle's database server is free to download (for Linux at least, not
checked other platforms). The license allows for development work - such as
providing Oracle support for WikiMedia :)
But I understand that contributions from people like myself - that want it -
should look at providing it.
greg wrote:
I heartily support this feature request as a request to provide an abstraction layer between
MediaWiki and the database.
I am trying to have my company adopt MediaWiki as our collaboration tool, and the major roadblock
I'm facing is that it requires the addition of another DBMS to the mix. We're a Sybase shop, and
it's a hard sell to tell management that our experience and infrastructure can't be utilized with
this. Regardless of performance benefits or any other really valid reason why MySQL should be the
datastore, the ability of our IT staff to manage the resource is paramount. We'd rather take a 100%
performance hit on the system rather than try to manage training for MySQL when we have over 50
Sybase DBA's at our fingertips.
If there's documentation on the database integration, I'd be happy to use that to do some work on
this that might allow other database systems to act as the MediaWiki datastore. That effort could
be leveraged by anyone looking to use Oracle, DB2 or anything else. If MediaWiki could become
database-independent, it would make a lot of our lives easier!
Looks like we have abstraction layer. Postgre support is in CVS, just missing
the installer support.
river wrote:
i now have enough Oracle support in my local MediaWiki to load
Special:Version:
MediaWiki: 1.5beta2 PHP: 5.0.4 (cgi-fcgi) Oracle: Oracle Database 10g Release 10.1.0.3.0 - Production
setting target milestone to 1.6, this won't be in 1.5.
slakkie wrote:
Using a ADODB abstractlayer will make everyone happy. And the problem solved for
once and all. There exists a php abstract layer, which is widely used.
(http://adodb.sourceforge.net/) maybe Mediawiki can be developed together with
these guys to have a perfect Abstract solution and therefore delivering very
high flexibility. I can image that huge companies will then change over to
Mediawiki very easily then.
Regards
we do not need DBAPI abstraction layer, we need query abstraction layer. This is
bigger value provided by our own abstraction classes.
And big companies can still use MySQL. And pay for it, even :)
river wrote:
reopening, since it's not really working properly yet. also removing target milestone since i'm not
going to finish this for 1.6. sorry.
no_spam wrote:
Hi.
I try to setup MediaWiki and get following result:
MediaWiki 1.6.5 Installation
announcements mailing list.
Checking environment...
Please include all of the lines below when reporting installation problems.
Attempting to raise limit to 20M... ok.
caching functions
you enable uploads.
Production -- mysql 4.0.14 or later required. Aborting.
coffeyman11 wrote:
Has there been any activity for this request in the last year? I would like
to implement Mediawiki in my company, but am running into the same resource
management issue as Greg in comment #7.
robchur wrote:
As far as I am aware, no; while the upkeep of PostgreSQL has been excellent, the
Oracle support has dwindled the point where it's probably safe to assume what is
there won't work out of the box.
Is your organisation willing to sponsor or assist with development?
Oracle support is not maintained and totally nonfunctional.
The remaining stub files will be removed unless someone shows up to actively
start working on them in the next, oh, few hours. (They can be restored later,
of course, if someone works on them.)
coffeyman11 wrote:
I work for a paperwork-loving government-contracting giant so its doubtful
they would feel compelled to let me work for a public project. I'm thinking a
little about supporting it on my own time, but my experience in PHP and SQL is
minimal. However, I do love the concept and would like to contribute...
river wrote:
i've tentatively re-implemented Oracle support in r20333. if anyone is still interested in MW on Oracle, please try this revision and see if it works.
there's no installer support, so you need to copy LocalSettings.php from somewhere else, and source maintenance/ora/tables.sql from SQLPlus. set $wgDBtype to
"oracle" and $wgDBname to your SID. $wgDBserver and $wgDBport are ignored.
the user MW runs as needs Oracle Text privileges so search can work.
pdhogan wrote:
I will be downloading the source for the Oracle abstractions and see if I can get it to work. I will update you if I have any success. We have two Oracle DBA's so we might be able to help and we have a need to get MediaWiki working on Oracle 10g.
I will keep everyone updated.
jasonrsears wrote:
I've had initial success getting the Oracle support to work. It took editing 18 files to get the queries inline with Oracle. Several had table aliases using the "AS" keyword and a number of GROUP BY predicates used numeric columns versus column names. I have all of the Special Pages working and would be very willing to offer these changes back to the project or others interested in seeing Oracle supported.
freak wrote:
(In reply to comment #23)
I've just commited updated Oracle abstraction to svn.
There have been some changes in DB schema (changed types and new tables/fields).
Could someone give it a try ... i've tested the changes against 9i, 10g and 11g, but 8i compatibility was made by heart.
Maintenance scripts haven't been updated yet.
Let me know how it goes.
marcusminervino wrote:
(In reply to comment #24)
(In reply to comment #23)
I've just commited updated Oracle abstraction to svn.
There have been some changes in DB schema (changed types and new
tables/fields).
Could someone give it a try ... i've tested the changes against 9i, 10g and
11g, but 8i compatibility was made by heart.Maintenance scripts haven't been updated yet.
Let me know how it goes.
I'm a Oracle DBA and want to hep you in the tests of Oracle abstration. We want to use mediaWiki with Oracle here. It is possible to you send instructions about install mediaWiki with Oracle Support?
I will apreciate any Help
Thanks a Lot
freak wrote:
svn-build already has Oracle support in the installer ... try that. If you have any problems you can contact me directly at freak -at- drajv -dot- si.
marcusminervino wrote:
Ok. One question. During the installation, How do I choose to use Oracle.
Do you have a MediaWiki Oracle Installer Guide?
Thanks a lot
marcusminervino wrote:
I recive this msg
Checking environment...
Please include all of the lines below when reporting installation problems.
PHP 5.2.6 installed
Found database drivers for: SQLite Oracle
PHP server API is apache2handler; ok, using pretty URLs (index.php/Page_Title)
Have XML / Latin1-UTF-8 conversion support.
Warning: A value for session.save_path has not been set in PHP.ini. If the default value causes problems with saving session data, set it to a valid path which is read/write/execute for the user your web server is running under.
PHP's memory_limit is 128M bytes.
Couldn't find Turck MMCache, eAccelerator, APC or XCache; cannot use these for object caching.
Found GNU diff3: /usr/bin/diff3.
Couldn't find GD library or ImageMagick; image thumbnailing disabled.
Installation directory: /usr3/ftps/mediawiki/phase3
Script URI path: /index.php
Installing MediaWiki with php file extensions
Environment checked. You can install MediaWiki.
Generating configuration file...
Database type: Oracle
Loading class: DatabaseOracle
Strict Standards: Declaration of DatabaseOracle::newFromParams() should be compatible with that of DatabaseBase::newFromParams() in /usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 156
Strict Standards: Declaration of DatabaseOracle::fieldExists() should be compatible with that of DatabaseBase::fieldExists() in /usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 156
Strict Standards: Declaration of DatabaseOracle::limitResult() should be compatible with that of DatabaseBase::limitResult() in /usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 156
Strict Standards: Declaration of DatabaseOracle::unionQueries() should be compatible with that of DatabaseBase::unionQueries() in /usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 156
Attempting to connect to database "ZABBIX"
Fatal error: Call to undefined function mb_check_encoding() in /usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 265
marcusminervino wrote:
I use this trunck of MediaWiki
svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3
It is the last one do you have talked about?
Thanks
You're right. That's the trunk version of MediaWiki, where all the development take place.
marcusminervino wrote:
Ok. But i have found the follow error (Please Help)
I recive this msg
Checking environment...
Please include all of the lines below when reporting installation problems.
PHP 5.2.6 installed
Found database drivers for: SQLite Oracle
PHP server API is apache2handler; ok, using pretty URLs (index.php/Page_Title)
Have XML / Latin1-UTF-8 conversion support.
Warning: A value for session.save_path has not been set in PHP.ini. If the
default value causes problems with saving session data, set it to a valid path
which is read/write/execute for the user your web server is running under.
PHP's memory_limit is 128M bytes.
Couldn't find Turck MMCache, eAccelerator, APC or XCache; cannot use these for
object caching.
Found GNU diff3: /usr/bin/diff3.
Couldn't find GD library or ImageMagick; image thumbnailing disabled.
Installation directory: /usr3/ftps/mediawiki/phase3
Script URI path: /index.php
Installing MediaWiki with php file extensions
Environment checked. You can install MediaWiki.
Generating configuration file...
Database type: Oracle
Loading class: DatabaseOracle
Strict Standards: Declaration of DatabaseOracle::newFromParams() should be
compatible with that of DatabaseBase::newFromParams() in
/usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 156
Strict Standards: Declaration of DatabaseOracle::fieldExists() should be
compatible with that of DatabaseBase::fieldExists() in
/usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 156
Strict Standards: Declaration of DatabaseOracle::limitResult() should be
compatible with that of DatabaseBase::limitResult() in
/usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 156
Strict Standards: Declaration of DatabaseOracle::unionQueries() should be
compatible with that of DatabaseBase::unionQueries() in
/usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 156
Attempting to connect to database "ZABBIX"
Fatal error: Call to undefined function mb_check_encoding() in
/usr3/ftps/mediawiki/phase3/includes/db/DatabaseOracle.php on line 265
marcusminervino wrote:
Only a problem. When I have tried to change my language, using the follow method:
If i change $wgLanguageCode to 'pt' or 'pt-br' the follow error appear on "/usr/local/apache/logs/error_log" (Apache)
"PHP Fatal error: Unsupported operand types in /usr3/ftps/mediawiki/phase3/includes/User.php on line 1015"
Please, any help you be nice!
Thanks
marcusminervino wrote:
Well. It works. I put "fr", "de" and finally "pt-br" and now works.. Mistery..
I have found a error while the system tried to insert in table CATEGORY. The "INSERT" comand tried to insert a register at the table without put a value to column CAT_ID
I create the follow triggere, and the error stops
CREATE OR REPLACE TRIGGER WIKI.TRG_CATEGORY
BEFORE INSERT ON WIKI.CATEGORY
FOR EACH ROW
WHEN (NEW.CAT_ID IS NULL)
BEGIN
SELECT CATEGORY_CAT_ID_VAL.NEXTVAL INTO :NEW.CAT_ID FROM DUAL;
END;
marcusminervino wrote:
Thanks a lot. One detail. I forgot to kick out of the trigger's code the "owner". Forgot it if you have already saw it.
CREATE OR REPLACE TRIGGER TRG_CATEGORY
BEFORE INSERT ON CATEGORY
FOR EACH ROW
WHEN (NEW.CAT_ID IS NULL)
BEGIN
SELECT CATEGORY_CAT_ID_VAL.NEXTVAL INTO :NEW.CAT_ID FROM DUAL;
END;
freak wrote:
Well all the other seqence queries are done in PHP, so the categories will not be an exception.
I personally would prefer trigers, but because oracle here is only an abstraction and there are no preformance issues i'll stick to the "standard".
I hope you can live with that...
freak wrote:
commited to svn ... also added missing logging tables columns.
Reopen this bug if you have ANY issues whatsoever with oracle ...