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