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

[Jeremy Epstein]

On 5/13/06, Dries Buytaert <dries.buytaert at gmail.com> wrote:
> The fact you didn't dig deeper into PostgreSQL until now, illustrates
> my point.
>
> People new to Drupal want to write code that works.  They are just
> scratching their own itch.  They want to tweak or extend Drupal, and
> they want it to be super easy to do.  Getting the job done, and done
> quickly while still feeling good about it, is what sucks them into
> Drupal. Portability is not a major concern until they are fully
> sucked into Drupal development.

Actually, I think it's my point that's being illustrated ;-). But then
again, I would think that, since it's _my_ point! It's all a question
of perception...

Fact (as you said): new Drupal developers just want to write code that
works, and they don't care about portability. So the only way that
we're ever going to get new developers (or experienced developers who
are in a hurry) to write portable code, is by forcing them to. If the
quickest way for Jane Newbie to get the job done is to copy some calls
to db_create_table() out of core, and to paste them into her
foobar_module.install file and hack them a bit, then that's what will
be done. This will take her about the same amount of time to complete,
as would copying and hacking plain SQL out of core. But, the side
effect will be that her install queries are database independent.

The process and the learning curve for new developers will remain
pretty much the same as it is now, except that instead of writing one
set of plain SQL 'CREATE TABLE' queries (that will only run on MySQL),
newbie_module_xyz will have one set of db_create_table() calls (that
will run on MySQL or on pgSQL). And let's face it, most new developers
will only need to know that ONE function - the details of which can be
learned by spending 5 minutes reading the specs page for it on
api.drupal.org.

I don't see this as being any different from the learning barrier that
already exists to support table prefixing. New developers must learn
the {curly bracket} syntax before they start writing any SQL in Drupal
- this is already an abstraction on top of 'plain' SQL queries.
Admittedly, the new proposed functions such as db_create_table() are
going to be a fair bit more complex than the prefixing syntax, but the
principle is the same.

Cheers,
Jaza.