[development] Referential integrity -- finally?

Dries Buytaert dries.buytaert at gmail.com
Tue Jan 23 17:35:41 UTC 2007

On 23 Jan 2007, at 13:04, Gerhard Killesreiter wrote:
>> I think there needs to be some effort put in to better the  
>> abstraction we currently have. e.g db_add_column() only exists for  
>> PostgreSQL. We'd get rid of a mountain of code if all updates were  
>> moved to use that function for both MySQL and PostgreSQL. It would  
>> also reduce the barrier for module developers to write PostgreSQL  
>> compatible code.
>> What do you guys think of this?
> Problem is that Dries doesn't like this _at_ _all_. :p
> His argument is IIRC that we should stick to as plain SQL as  
> possible to not further increase the barrier of entry for people  
> already knowing SQL.

When working with databases you want to know _exactly_ what is  
happening with your fields, types, keys and indices -- and the order  
thereof.  An abstraction layer makes that less transparant.

Plus, SQL is already an abstraction layer so we'd be adding an  
abstraction layer on top of an abstraction layer.  It's a little  
implementing a new template language in PHP (cfr. Smarty) -- PHP is  
already a template language.

At the same time, an abstraction layer makes it easier to port and  
update modules.

Conclusion: there is no win-win situation -- each direction has  
advantages and disadvantages.

> While his argument has merit, I think it is put ad absurdum by the  
> fact, that Drupal doesn't have any plain sql files anymore.

Yes, with the install system, the facts has changed.  "Ad absurdum"  
is too strong a word (but it sure sounds cool. ;)  I don't mind us  
opening this discussion again.

The more I think about it, the more it boils down to this question.   
What do we care more about?  Optimizing Drupal for developers, or  
getting more database experts on board?

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

More information about the development mailing list