[development] Extend database abstraction layer, to include table creation.

Adrian Rossouw adrian at bryght.com
Thu May 11 18:31:32 UTC 2006


http://drupal.org/node/63049

Now that we have .install files for modules, I believe it is time we  
extended our database abstraction layer.

I recommend we create the following extra functions :

1. db_create_table($tablename, $columns); // columns is an  
associative array with the 'name' => 'type'
3. db_drop_table($tablename);
3. db_create_index($tablename, $columns); // columns is an array of  
column names, or just a single column.
4. db_drop_index($tablename, $columns);
5. db_add_column($tablename, $column, $type); // PGSQL already has a  
similar function, but it isn't in both systems.
6. db_drop_column($tablename, $column);

The installer that is coming in, will be converting the database.*sql  
files into a system.install file, and with these functions, we can  
collapse ALL THREE SCHEMA FILES, into a single, much simpler file.

This will also _drastically_ simplify updates, and it will give us  
consistent usage of types across the database.
Certain things will still need to happen only on postgres (like  
create function calls for instance), but this DRASTICALLY decreases  
the amount of work we have to do to support multiple db types.

At the moment, there are no create table statements that can be  
changed in core itself (until we have a system.install) , however,  
contrib modules can already be ported to use these functions, which  
would mean that we have (preliminary) postgres support across the  
board on all contrib modules.

These functions should possibly keep track of what tables / columns /  
indexes have already been created, that would allow us to check (in a  
cross db way) what tables are available, and maintaining this  
information could possibly be useful in the future, such as not  
creating tables which have already been created.

Additionally, each of these functions can be used to trigger a  
process for entering additional database credentials, in the case  
that the specific database user is not allowed to create tables and  
the like.

This also helps make the patch for the installer a lot simpler, so if  
you want to help out with the installer, this would be a good thing  
to get involved with =)

--
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com




More information about the development mailing list