[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