By RBobowski on

I've read through many posts regarding Drupal support for various databases other than MySQL and PostGreSQL. There appears to be reasonable activity in regards to an Oracle port. I've read through some of the code in the CVS repository and it appears that there is some type of database abstraction layer in Drupal.

Is the database abstraction layer implemented well enough that it is practical to create interfaces for other databases?

It seems like PostgreSQL was added within the last year or so, but I picked up on some things from the Oracle port effort that made me think that there may be some serious problems with the current abstraction implementation that would require someone to touch a lot of the core Drupal codebase. Any comments from persons familiar with the code base or someone who worked on the PostgreSQL port would be appreciated.

Obviously, module developers are free to ignore the abstraction facilities. But, are there any similar problems with the core features of Drupal? I'm assuming that the code in the core Drupal system always observes the abstraction conventions, but I'd like confirmation of this from someone familiar with the code base to answer this question.

Here's a list of the source files that I'm aware of (after a quick look) that will need to be updated and or created to implement an additional interface for another database. Please let me know which files I've overlooked.

database.inc
database."db_name".inc (for example database.mssql.inc)

install.inc
install."db_name".inc (for example install.mssql.inc)

I am very interested in creating (a serious effort) an interface for MS SQL and would consider the project worthwhile if the Drupal core code works with the abstraction layer.

I think that a secondary effort to create some type of syntax tests to validate the compatibility Drupal modules with the abstraction facilities would also be worthwhile and could possibly be started with the work done to create an interface for MS SQL. This would allow module developers to superficially test their code for compatibility. Any thoughts on this idea? Maybe work has already started in this regards.

Thanks in advance for you responses.

Comments

robertdouglass’s picture

robertdouglass commented

I'm sure you've seen this article, but if not, it could be a useful resource: http://www-128.ibm.com/developerworks/ibm/library/i-osource9/index.html

Postgres has been supported for more than a year. It's been supported for as long as I've used Drupal, as far as I recall.

Core observes all of the proper abstraction conventions. Most good modules do as well.

You might want to start a working group on groups.drupal.org. Currently, the only active database related groups is for scalability:
http://groups.drupal.org/database-scalability

There have been previous efforts for a MS SQL layer. I recommend asking on the devel mailing list for feedback from the people who have addressed the issue before. You may get useful code or tips on known pitfalls:
http://drupal.org/mailing-lists

- Robert Douglass

-----
Lullabot | My Drupal book | My Digg stories

chx’s picture

chx commented

He created an MS SQL support patch very recently: http://drupal.org/node/74308 . It's too late for Drupal 5 but I would like to see this in Drupal 6.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | Wake in the deepest dark of night and hear the driving rain. Reach out a hand and take a paw and go to sleep again.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

peterx’s picture

peterx commented

ADOdb provides the first well developed abstraction for many databases. One of the things ADOdb did that is not in Drupal is the provision of date conversion functions so that you can specify dates in the international standard and have them converted to the format used by the database.

In Oracle's case, the early releases used a proprietary date format, the middle releases used the proprietary format as the default and had an option to change the default to the international format. ADOdb did whatever was required if you chose to use ADOdb functions for your dates and, in the case of Oracle, you told ADOdb the correct release. When you create SQL for Oracle, please document the release and any Oracle settings to change the interpretation of SQL.

There are structural changes you may want to make as well. Early MySQL did not have nested queries and some Oracle stuff does not work efficiently unless you use nested queries. When you write a special version of an SQL statement for Oracle, please document why you changed the SQL so that future generations can understand and maintain the change.

petermoulding.com/web_architect

petermoulding.com/web_architect

RBobowski’s picture

RBobowski commented

Thanks for the quick responses. I'm looking into these leads.

Paul Natsuo Kishimoto’s picture

Paul Natsuo Kishimoto commented

... you can push for database abstraction by commenting on feature requests for 6.x, like 87074.

daneelcm’s picture

daneelcm commented

Hey, i would like to know if you advance in this. I think like you and was looking for ADO DB too, it was nice can be a drupal installation in a mssql server. If you abandon the work tell me why, it's impossible? Thank's.

peterx’s picture

peterx commented

Drupal 7 uses the PHP PDO feature to make compatibility easier then adds the Field module (similar to part of CCK) for database column definition. The approach achieves something similar to ADO DB and should be faster because the PDO part is processed in PHP, not in your code. People who use mssql and other databases should focus on Drupal 7 because Drupal 7 is designed for, and actively tested, using several datases. There might be a Drupal mssql group with the latest information.

petermoulding.com/web_architect