I've actually been thinking .. we now have db_add_column for updates ... would it not make sense to introduce : function db_create_table($name, $columns = array("col" => "type")) { and of course db_create_index. From an install system perspective, it might be really useful to actually keep a catalog of what tables are created by drupal itself, and it would help us be able to manage things like shared tables directly from Drupal. We might even be able to automatically generate some of the updates / schemas. ie: when someone commits a new .install file, it dry runs the _install function and then sees if any columns / tables have been added , and then creates _update_<x> stub functions for that automatically. Of course these would need to be edited for more comlpex schema changes, but it might cut down some development time for developers. I'm thinking we could write a generate_schema.php file which then looks at all the .install files in the current path, and generates a .mysql file from that. (for those admins that don't allow people to have access to create table and the like) On 12 Dec 2005, at 11:59 AM, Piotr Krukowiecki wrote:
On Sun, Dec 11, 2005 at 06:59:25PM -0500, Moshe Weitzman wrote:
folks - when you are making .mysql or .pgsql files for your modules, please don't add risky statements like: DROP TABLE IF EXISTS subscriptions;
Why they should not be used in .mysql files?
someone started this trend years ago and it gets repeated like a parrot. don't be a parrot. thanks.
The same can be said about "int(11)" etc.
-- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com