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 dumps 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 break. 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 shouldn't be 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 MySQL 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 functions, exclusively meant for the .install files.
We already have some of these functions, but only for postgres, and these functions 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. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com