[development] Extend database abstraction layer,
to include table creation.
adrian at bryght.com
Sat May 13 15:39:38 UTC 2006
On 13 May 2006, at 5:17 PM, Angela Byron wrote:
> But I have a question... would the introduction of db_create_table()
> mean removing the ability to just continue copy/pasting PHPMyAdmin
> into db_query()? Or are we simply proposing some additional API
> functions for developers who wish to write portable SQL code in an
> easy way?
They can't do that now with the install system anyway.
If you put table creation code "FOR A MODULE" into phpmyadmin, it won't
update the schema versions, and your updates, when they happen. Will
Sure, you're free to just not use the install system for that module
at all, but
at that point you should not be distributing your module, and it
in drupal.org cvs for consumption by other people.
Keep in mind, putting sql into phpmyadmin also doesn't to table
prefixing, and all the other
things a distributed module should do.
If you distribute your code on drupal.org, you should be using the
install system and if you
are using the install system, you should be using the abstraction layer.
> It seems to me we could have the best of both worlds by not
> changing the
> current behaviour of db_query(), and instead just introducing some
> additional API calls for more "advanced" developers who understand
> but maybe don't know PostgreSQL and would like to write portable code
> could do so without needing to install PostgreSQL and read the whole
> manual there (which is another learning curve :)).
Nobody suggested changing db_query at all. These are some extra
exclusively meant for the .install files.
We already have some of these functions, but only for postgres, and
have cleaned up the postgres updates significantly.
What it comes down to, is these functions are essentially 'theme()'
functions, but for sql statements.
Nothing more, nothing less.
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com
More information about the development