Postgres support is very very far from high priority, but when we do have it, it would make more sense to maintain 1 provision_db_server module that extends drupal's existing db api. ie: provision.mysql.inc and provision.pgsql.inc.

even less of a higher priority is multiple web server (ie: apache/lightppd etc) support, but something similar could be useful if we wanted to implement multiple TYPES of apache hosting (ie: clusters, web front ends, etc).

Comments

anarcat’s picture

Title: Turn all provision_mysql speciality functions into db_mysql functions, to integrate with database.inc » Turn all provision_mysql speciality functions into provision_db functions, to integrate with database.inc

Make it clear that we want to abstract the database layer here.

adrian’s picture

Status: Active » Postponed

This can't be done until we're on D7 with the new db layer.

so this is a very very long time away.

adrian’s picture

Title: Turn all provision_mysql speciality functions into provision_db functions, to integrate with database.inc » 0.3 - Move to PDO for all database access
Version: 5.x-0.1-alpha1 »

We now no longer rely on the drupal database layer at all, and drush 2.x now requires php 5.2, so we can rely on PDO always being available.

The only functions that need to differ for PG are :

function _provision_mysql_new_site_db($db_name, $db_user, $db_passwd, $db_host) {}
function _provision_mysql_destroy_site_db($db_name, $db_user, $db_passwd, $db_host) {}
function _provision_mysql_database_exists($name) {}
function _provision_mysql_create_database($name) {}
function _provision_mysql_grant($name, $username, $password, $host = '') {}
function _provision_mysql_revoke($name, $username, $host = '') {}
function _provision_mysql_import_dump($dump_file, $db_name, $db_user, $db_passwd, $db_host) {}

At least for D6 sites, this should allow us to have full postgres support for drupal (in as far as the drupal postgres port actually works).

This would also give us access to sqlite, which might be useful for some interesting problems.

anarcat’s picture

Title: 0.3 - Move to PDO for all database access » Move to PDO for all database access
Status: Postponed » Active
Issue tags: +aegir-0.4

Tagging for 0.4.

anarcat’s picture

This is a requirement of #585796: postgresql backend support.

mradcliffe’s picture

Main purpose of this post is to subscribe to get this into my issue queue.

I think a small provisionPDO class might be sufficient (not extending PDO itself). The constructor and destructor can handle a connection with other methods such as query, results, db_exists (?), create/drop_db, grant/revoke, and some others.

adrian’s picture

we need to move them into drush engines, and conditionally include them based on a flag.

i'm open to making them classes too.

in fact, this might help a lot in our future work for server stuff.

adrian’s picture

Status: Active » Fixed

this is done in dev-services.

Status: Fixed » Closed (fixed)
Issue tags: -aegir-0.4

Automatically closed -- issue fixed for 2 weeks with no activity.