[development] Referential integrity -- finally?

[Sammy Spets]

I agree that a schema definition is best left to be standard SQL for
many reasons. Most importantly, Dries mentioned, is lowering the barrier
for new module developers. New modules aren't the issue for me because
the number of new modules added to the repository are far lower than the
number of updates written.

My quest is really to get the updates (usually done after a module 
developer has gained some experience) performed through abstracted 
functions. This would considerably lower the amount of work required by 
people in my position. If it works in MySQL, it works in PostgreSQL. 
Simple.

Adding a table to a database is very easy to test. Meaning it's dealt
with quickly if a module developer contacts someone savvy with
PostgreSQL. Likewise, if the module developer is writing an update and
finds they need something other than what's provided by the abstraction
functions. In that event, they can contact someone savvy with PostgreSQL
to assist them to write the PostgreSQL part.

Several people are talking to me about some update code they are writing
when it goes outside their PostgreSQL scope. This has been fantastic for
Drupal because people using PostgreSQL don't get install errors or 
errors when they update some module.

All i'm suggesting is we move the update code to abstracted functions 
and leave hook_install() as is.

-- 
Sammy Spets
Synerger Pty Ltd
http://synerger.com

On 23-Jan-07 18:35, Dries Buytaert wrote:
> 
> 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/