[development] Data-driven database tables and updates

Alan Dixon alan.g.dixon at gmail.com
Wed Jun 14 17:15:08 UTC 2006

I hope you haven't all left the building yet ...

it seems to me that there are two valid points here that are really
looking at two different pieces.

Specifically, as a module developer, I like my sql calls to be as
direct as possible, not just because i don't want to learn something
new, but mainly because I want it easier to debug (i'm syntaticly
challenged...). Having to follow what's going on through a complex or
opaque layer of abstraction is a huge waste of time (even assuming
there's no bugs in it!).

But I think that doesn't preclude an abstraction layer for automated
scripts in core and contrib, where we can benefit from folks who have
more sql expertise. I'm not a fan or cogenscenti of excessive
abstraction, but I've been convinced by this thread of its benefits at
the level of managing complexity and change ...

So how does this split up? Well, it seems to me this is related to the
whole discussion of the contribution modules and separating out the
'drupal-ready' stamped ones vs. the 'it worked on my site once upon a
time' modules. So, part of the whole testing rigamarole that modules
would have to go through in the process of getting some kind of stamp
of approval would be to follow the required schemas of the abstraction
layer that would allow for better automated scripts.

$0.01 worth ...

On 6/9/06, Dries Buytaert <dries.buytaert at gmail.com> wrote:
> On 09 Jun 2006, at 19:44, Adrian Rossouw wrote:
> >> Adrian Roussow is working on something like this already.
> > I wish I was. But sadly Dries has (in no uncertain terms) said he
> > didn't like the idea.
> If the majority of the people think this is a good idea, I'd be happy
> to go with this direction.
> As mentioned, I understand the advantages of said system, but I still
> prefer the transparency and simplicity of "raw" SQL statements.
> SQL is an abstraction layer, and one that is documented in hundreds
> of books and articles.   It is my opinion that creating a Drupal-
> specific abstraction layer on top of an existing, standards compliant
> abstraction layer used by hundreds of thousands of people creates an
> additional barrier for developers that are new to Drupal, but that
> are familiar to SQL.
> I, for one, wouldn't want to learn an application specific SQL-like
> description language.  As a developer, it would sorta turn me off,
> and make me shout 'bloat!'.

Alan Dixon, Web Developer

More information about the development mailing list