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.