[development] Extend database abstraction layer,
to include table creation.
drupal at dwwright.net
Sat May 13 11:15:45 UTC 2006
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...
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.
More information about the development