[development] no DROP TABLE in sql files

[Adrian Rossouw]

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