{SPAM 01.8} Re: [development] Data-driven database tables and updates

[Adrian Rossouw]

On 10 Jun 2006, at 4:03 PM, Moshe Weitzman wrote:

>> creation. At best it will be lowest common denominator, and  
>> performance
>> cannot be achieved without tweaking to the specific database.
>
> please, we are only talking about schema definitions. performance  
> is a non issue.
Not necessarily.

Different databases could still have different optimal index  
configurations.

This code is meant to cover the 95% of cases, however.
And there's nothing stopping us from still using

if ($db_type['mysql']) {
  // some mysql specific alterations / optimisations
}

It's not a way to stop people from having to learn sql. SQL is still  
a pre-requisite for
developing with Drupal. It is only meant to save the developer from  
having to know
2 or 5 different variants of sql just to fully support our feature  
set. It is still almost
exactly like sql, it's just broken up into a more readily accessible  
data structure for
us to work with it.

When it comes down to it, the code is in all practicality like theme 
() functions for
sql statements. Switching to different output based on db_type, not  
different selected
theme.

I am also ok with using the sql parser found here (http://cvs.sf.net/ 
viewcvs.py/easymod/sql_parser/root/includes/sql/)
since the end result is the same.

Whether Dries wants to admit it or not, the current inequality of  
postgres and mysql
support is a maintenance nightmare. Now that automated installs are  
happening,
the demands of keeping the code in synch are only going to grow, and  
the problems
from failing to do so, will become more apparent.


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