[development] Data-driven database tables and updates

[Boris Mann]

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!'.

What about a simple helper script that sucked in .mysql files and
generated it for you? You could then learn the app specific stuff if
you wanted to do some of the special tricks or abilities that this
enables.

I agree that adding yet-another-special-Drupal thing adds complexity
for new developers. But part of what makes Drupal interesting/powerful
is some of our helper functions and abstraction layers.

Reading Ken Rickard's description of how Drupal helped him learn good
PHP is very interesting:
http://ken.therickards.com/2006/06/04/tech-notes/

Clearly, this is one of those areas where some small group of folks
will have to join forces and give this a shot to see if it makes
sense, and then we can poke holes in running code.

-- 
Boris Mann
Vancouver 778-896-2747
San Francisco 415-367-3595
Skype borismann
http://www.bryght.com