[#557] by PHP-PDO : Add several database server/relational database management system (RDBMS) support in FusionForge



Detailed description


FusionForge support only Postgresql as database server / relational database management system (RDBMS : http://en.wikipedia.org/wiki/Relationaldatabasemanagement_system), but some users or companies/enterprise have only database administrator that know only one database server. Then these users will use other Forge software as (because they don't want or have no time to learn to manage a new database server) : * Redmine with database support : Mysql, Postgresql, MS SQL Server, SQLite (http://www.redmine.org/projects/redmine/wiki/RedmineInstall) or * Trac with database support : Mysql, Postgresql, SQLite (http://trac.edgewall.org/wiki/TracInstall#MandatoryDependencies)

In 2008, the 4 top more used database server are : Oracle DB, MS SQL Server, Mysql, IBM DB2 (Source : http://www.mysql.com/why-mysql/marketshare/ ) I found no more up to date numbers. Some information in monthly database report here : http://www.tdan.com/view-featured-columns/16896

Then can you add Postgresl and Mysql database support in FusionForge 5.3.x by PHP PDO ?

PDO (mysql) http://www.php.net/manual/en/intro.pdo.php

The PHP Data Objects (PDO) extension defines a lightweight, consistent interface for accessing databases in PHP. Each database driver that implements the PDO interface can expose database-specific features as regular extension functions. Note that you cannot perform any database functions using the PDO extension by itself; you must use a database-specific PDO driver to access a database server. PDO provides a data-access abstraction layer, which means that, regardless of which database you're using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility.

Mysql PDO tutorials :

http://www.phpmaniac.net/wiki/index.php/PHPPDO#PostgreSQLExample http://wiki.hashphp.org/PDOTutorialforMySQLDevelopers http://net.tutsplus.com/tutorials/php/why-you-should-be-using-phps-pdo-for-database-access/ http://blog.pascal-martin.fr/post/php-arretez-utiliser-fonctions-mysql http://randomdrake.com/2011/08/02/php-developers-finally-deprecating-extmysql-in-favor-of-mysqli-or-pdo/ http://www.phpeveryday.com/articles/PDO-Portable-Connection-to-Database-P547.html

General Information
Submitted by:
Yannick L
Date Submitted: 2013-04-24 11:37
Last Modified by: Nobody
Last Modified: 2017-11-02 20:00
Permalink: https://fusionforge.org/tracker/a_follow.php/557
Internal Fields
Data Type: Feature requests
Assigned to: Nobody (None)
State: Open
Priority: 1
Extra Fields
Target release:
Follow-up tabs
Message  ↓
Date: 2014-05-05 13:16
Sender: Sylvain Beucler

While PDO sounded like a good idea 5 years ago, nowadays I would recommend targetting an ORM such as Doctrine. If we invest a lot of work into DB changes, let's get a lot of value out of it :)

Date: 2013-05-03 11:54
Sender: Roland Mas

It's not the first time someone has suggested making FF more database-agnostic, and the problem is twofold.

First, wrapping the database calls inside functions that are not specific to one DB engine. This is done already: the code uses our own dbquery* functions rather than pg* functions, for instance. Adding a layer of using pdo* functions somewhere in there would be trivial (and mostly useless).

The second part is writing queries that will work with all database engines. This is the hard part, because FF uses some features of PostgreSQL that are not available on other databases, or with a different syntax, or different semantics, and so on. Various kinds of foreign keys, triggers, stored procedures, views, parametrized queries, locale-aware full-text indexing, etc. There is some logic that is implemented at the database level rather than (or in addition to) the PHP level, and it relies heavily on the combination of features and syntax provided only by PostgreSQL so far. Emulating these features in PHP would make the code more complex and less maintainable. I don't think anybody would object if someone offered a guarantee that it would be maintained, but so far nobody has even proposed writing the code.

My (cynical) view on this feature request is that can't be that interesting. If it was, somebody would have implemented it at some point in the last 10 years.

Date: 2013-04-27 12:50
Sender: Franck Villaume

PDO might be a good idea. Probably not in 5.3.x Maybe Fusionforge 6.x

Date: 2013-04-24 17:21
Sender: Alain Peyrat

Moved from Bugs to Feature requests

Date: 2013-04-24 13:23
Sender: Yannick L

>MySQL is not a database, it’s not even ACID. Mysql is a database server and it is ACID with InnoDB storage engine : http://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine.html http://dev.mysql.com/doc/refman/4.1/en/innodb-storage-engine.html

In the sql file, you can choose to create mysql database with only innodb storage engine. exemple : http://dev.mysql.com/doc/refman/5.1/en/using-innodb-tables.html

>I think FusionForge is a “boxed solution”. No, a user can choose several components part as plugins or web server for storing or processing data.

>You do not normally let it point to an external DB server, so you >should treat the DB as part of it. No, sometimes if you want a better scability or because you use DMZ security network zone, you need one server for Apache/PHP (external DMZ zone) and an other for database server (internal DMZ zone) .

>Also, it makes use of stored procedures, and heavy use of >transactions, which I think is a good thing.

stored procedures are available in mysql 5.1 http://dev.mysql.com/doc/refman/5.1/en/stored-routines.html

transactions are available in Mysql 5.1. http://dev.mysql.com/doc/refman/5.1/en/innodb-transactions-with-different-apis.html

Date: 2013-04-24 11:43
Sender: Thorsten Glaser

MySQL is not a database, it’s not even ACID.

I think FusionForge is a “boxed solution”. You do not normally let it point to an external DB server, so you should treat the DB as part of it.

Also, it makes use of stored procedures, and heavy use of transactions, which I think is a good thing.

No attached documents

No related commits.

Field Old Value Date By
priority32018-04-22 08:59
Franck Villaume
Target release6.02015-01-04 15:26
Franck Villaume
Target releaseNone2013-05-01 13:29
Franck Villaume
DifficultyNone2013-04-27 12:50
Franck Villaume
typeBugs2013-04-24 17:21
Alain Peyrat

No relations found.