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

[Moshe Weitzman]

There certainly is a cost for this extra abstraction layer. But the beneits
are substantial, and IMO, outweight the costs you've identified. Expanding
on my response in this issue (http://drupal.org/node/63049)

- automatically gives us pgsql compatibility for most modules. Only those
that use non standard sql are broken.
- paves a clear path toward fixing the slight security problem we introduced
with 4.7. Since the install and update systems regularly create and drop
tables, an admin has to give the DB user those permissions. For 4.8 we want
the admin to have the option of defining a one $db_url for usual queries and
another for database definition queries. Database definition queries will go
through the aforementioned functions and at that point we can challenege the
user for uid=1 credentials or something else.
- specific to the installer, adrian mentions that our three schema files
unify to one. also, consider how much code gets thrown out when you take
every update in every contrib module and remove the pgsql branch. We will be
defining updates only once.

So, it might be true that installer should proceed without this. But The
benefits are substantial IMO and is a project worth doing IMO. It isn't that
hard either.

-moshe


On 5/12/06 12:00 PM, "Dries Buytaert" <dries.buytaert at gmail.com> wrote:

> 
> 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/