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

Dries Buytaert dries.buytaert at gmail.com
Fri May 12 16:00:54 UTC 2006

On 11 May 2006, at 20:31, Adrian Rossouw wrote:
> 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.

Can't we move forward without these functions?  It looks like we are  
introducing more and more dependencies to that makes it harder to  
move the install system forward.

While an additional database layer (SQL is already an abstraction  
layer) makes it easier to port Drupal to other database systems, it  
makes it harder to understand what is going on.  It is a lot less  
accessible to people that are new to Drupal, but that do have a SQL  
background.  So personally, I'm not all that convinced that these  
functions are a good idea ...

I, for one, find it much easier to read an SQL statement than some  
(new) Drupal-specific table definition.  I don't want to learn or use  
a such definition language.  Such functions make the database scheme  
less transparent.

Dries Buytaert  ::  http://www.buytaert.net/

More information about the development mailing list