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

[Derek Wright]

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.

On May 13, 2006, at 2:51 AM, Dries Buytaert wrote:

> For most of us eliminating the various SQL schemas makes perfect  
> sense.  After all, most of us are expert Drupal developers, and as  
> such, an incremental improvement is easy enough to deal with.   
> However, for new Drupal developers, who are not intimate with  
> Drupal's code, this just increases the barrier.
> ...
> This requires that we question certain development directions and  
> look at them through the eyes of amateurs.

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.

i'm about to face the prospect of setting up 2 very important sites  
(at least important to me *grin*) that will have to run on postgres  
for reasons beyond my control.  i know *nothing* about postgres, and  
i'd really rather i didn't have to port any contrib modules to it.   
if this abstraction layer will help eliminate that problem, i'm all  
for it.  furthermore, i've spent quite a few hours already dealing  
with patches that needed to be re-written since i missed another spot  
where i should have changed a schema, dealt with merge conflicts  
caused by this sort of thing, etc.  the schema duplication and DB  
update code is some of the least elegant (and hardest to maintain)  
code in all of drupal (at least the parts i've seen).

1 last point: the software i write for my day job is a huge, horribly  
complex, very low-level system that runs on most versions of UNIX and  
windoze.  we've made copious use of abstraction layers over the years  
to hide the ugly details of various aspects of platform-specific  
garbage.  the overwhelming majority of the code can now be written  
without worrying about if you're on a windoze, macos, linux, or  
*gasp* hpux10 machine (yeah, we've ripped out the ultrix 4.2 code by  
now, though it used to work there when i started).  porting to a new  
platform mostly entails porting a small handful of the abstraction  
layers, not the million+ lines of code.  adding new features can be  
done by people who don't really know anything about the trickier  
aspects of how solaris handles a certain system call.  sure, it takes  
time to learn our internal APIs, but i think it's still a win over  
trying to learn the entire system API for ~15 different platforms.   
grad students trying to crank out a new daemon as a research project  
can get something up and running that listens on a socket (which can  
be authenticated with SSL, Kerberos, etc), handles TCP and UDP  
commands, does logging (with file locking, rotating, different  
severity levels, etc), traps signals, and can handle periodic timers,  
all with about 100 lines of code against our internal APIs.  of  
course, drupal is facing different challenges, and most of the  
portability problems are handled by httpd and the php binary.   
however, i think there are analogies that are still relevant  
(especially when talking about db support).

food for thought...

-derek (dww)

p.s. there's an old saying in computer science circles: "all problems  
in computer science can be solved by caching and/or adding another  
level of indirection."  there's much truth to that.