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

[Dries Buytaert]

On 13 May 2006, at 13:15, Derek Wright wrote:
> in general, i totally agree with the thrust of what dries is saying  
> about trying to keep drupal easier to develop for.  however, i also  
> think adrian is right in this specific case that such a table  
> creation and modification abstraction layer would be a good thing.

That is the thing.  I agree with Adrian as well (I can see the  
advantages), it's just that we need to be careful and look at this  
from a beginner's point of view.  We should avoid turning this thing  
into a system that quacks like an enterprise-level CMS.  In such  
systems, you can define database schema's using XML, but at the end  
of the day, they aren't used as much as Drupal.  Guess why?   Part of  
the answer is that no one can install or customize such system  
without hiring a consultant.  That's not where we want to go.

> i'm not exactly an amateur, but i didn't know *any* SQL syntax as  
> of 5 months ago when i first tried setting up a drupal site for my  
> band.  for me, the kind of abstraction layer adrian proposed (and  
> others expanded on) would have probably helped me get up to speed  
> more quickly.  maybe i'm in the tiny minority of potential drupal  
> developers who aren't already SQL wizards, but who know how to  
> write code (i didn't know php either, but the syntax is enough like  
> perl and C and the docs are good enough that i could figure it  
> out).  however, from my perspective as still something of a drupal  
> novice, i don't think this would have slowed me down or deterred me  
> in any way.

How can you understand the table definition proposed by Adrian (see  
below), if you don't know any SQL?  I don't think this gets you up to  
speed any more quickly.  Quite the contrary, you'd first have to  
learn SQL and then you have to figure out how this Drupal specific  
definition format maps onto it.  Make no mistake, a Drupal-specific  
definition language is no excuse for not having to learn MySQL.  It  
does add an additional step to the learning curve!

       db_create_table('client_system', array(
         'cid' => array('type' =>  'int', 'NOT NULL' => TRUE,  
'PRIMARY KEY' => TRUE),
         'name' => array('type' => 'short text', 'NOT NULL',  
'default' => '', , 'PRIMARY KEY' => TRUE),
         'type' => array('type' => 'short text', 'NOT NULL',  
'default' => ''),
       ));

Hundreds of books have been written about PHP and MySQL.  As a  
newbie, you can buy these books and understand what Drupal's MySQL  
schemas mean.  If we add an extra abstraction layer, these books are  
going to be less useful.  Hence, we added a barrier.

It does, however, help you write portable code, but that isn't  
something most people are concerned about.  Newbies want to write  
code that works, and that they can understand.  Being able to  
understand something is very rewarding/motivating.  Portability is  
not their main concern.  IMO.

I'm not saying that the database definition function is a bad thing  
or that we should drop it on the floor.  We have to carefully  
evaluate whether the advantages (portability) outweight the drawbacks  
(less developers).  All I can say, is that, as a programmer, I can  
write SQL faster than I can write db_create_table() definitions.   
Plus, I value the transparency of the "raw" SQL statements; at least  
I know _exactly_ what is going on under the hood.

Here is something to think about (I'm still trying to figure out the  
best way to formulate this):

    The net effect of creating abstracting layers for everything is that
    you're building a new programming language on top of the existing
    languages (eg. PHP and MySQL).  At some point, you'll loose some of
    the underlying languages' advantages (eg. available documentation,
    talent pool, transparency).

You see this happen in the Java world.  Because of all the layers  
(EJBs, Struts, JSTLs, JSPs, Beans, CMP, BMP, JAXM), J2EE started to  
live a life on its own.  Being a "regular" Java developer isn't  
enough to get certain jobs.

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