folks - when you are making .mysql or .pgsql files for your modules, please don't add risky statements like: DROP TABLE IF EXISTS subscriptions; someone started this trend years ago and it gets repeated like a parrot. don't be a parrot. thanks. -moshe
FWIW Op maandag 12 december 2005 00:59, schreef Moshe Weitzman:
folks - when you are making .mysql or .pgsql files for your modules, please don't add risky statements like: DROP TABLE IF EXISTS subscriptions;
someone started this trend years ago and it gets repeated like a parrot. don't be a parrot. thanks.
ber@penelope:~/repository/contributions$ find modules/ -type f -name '*ql' -exec grep -l 'DROP TABLE' {} \; modules/survey/survey.mysql modules/freelinking/freelinking.mysql modules/mail_archive/mail_archive.mysql modules/fileserv/fileserv.mysql modules/authorise/database/taxoauth.pgsql modules/privatemsg/privatemsg.mysql modules/amazontools/amazon.pgsql modules/taggame/taggame.mysql modules/family/schema-drop.mysql modules/subscriptions/subscriptions.mysql modules/subscriptions/subscriptions.pgsql modules/smileys/smileys.mysql modules/epublish/epublish.sql modules/translation/translation.mysql modules/chatbox/chatbox.mysql modules/chatbox/chatbox.pgsql modules/contact_dir/contact_dir.mysql.sql modules/spam/spam_surbl/spam_surbl.mysql modules/wordfilter/wordfilter.pgsql modules/wordfilter/wordfilter.mysql modules/links/links.pgsql modules/links/links.mysql modules/weblink/weblink.mysql modules/shootevents/shootevents.mysql modules/gsitemap/gsitemap.mysql modules/libdb/libdb.mysql modules/libdb/libdb.pgsql -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
On 12 Dec 2005, at 10:38 AM, Ber Kessels wrote:
FWIW FWIW : 4.7 now ships with the ability to upgrade your modules through update.php
I have yet to see any documentation about this though. Drumm ? -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Monday 12 December 2005 03:38, Ber Kessels wrote:
modules/links/links.pgsql modules/links/links.mysql
Yikes! That's mine! I had those DROP statements in there for early prototyping, when I really *didn't* want to save the data. I thought I had taken them out after the schema stabilized. I'll take care of this right away...thanks for letting me know. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
For testers, it would be convenient to automate reseting drupal to close to the just installed state. This would include DROP TABLEs, caches, cookies, etc. I don't have root access and am left with files owned by apache so having apache clean them up would be nice. For instance I currently have drupal installed in /drupal-cvs while it will move to root when things are stable. That will leave me with a drupal-cvs directory that I can't delete.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Syscrusher Sent: Monday, December 12, 2005 9:51 AM To: development@drupal.org Subject: Re: [development] no DROP TABLE in sql files
On Monday 12 December 2005 03:38, Ber Kessels wrote:
modules/links/links.pgsql modules/links/links.mysql
Yikes! That's mine!
I had those DROP statements in there for early prototyping, when I really *didn't* want to save the data. I thought I had taken them out after the schema stabilized.
I'll take care of this right away...thanks for letting me know.
Scott
-- -------------------------------------------------------------- ----------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
the just installed state. This would include DROP TABLEs, caches, cookies, etc. I don't have root access and am left with files owned by apache so
I use a simple one-liner for deleting the Drupal database: mysql drupal -e "SHOW TABLES" | awk '{print "DROP TABLE "$1";"}' | tail +2 | mysql drupal That prints out every table in the "drupal" database, adds a "DROP TABLE" prefix, and then pipes it back into MySQL. After that, it's just a simple matter of "mysql drupal < database/database.mysql", and I'm back to square one, WITHOUT having to reset MySQL authentication (or the settings.php). It's worked well enough in everyday usage. -- Morbus Iff ( united we're bland ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
modules/libdb/libdb.mysql modules/libdb/libdb.pgsql
For what it's worth, mine are commented out, with clear documentation on their purpose. I stand by their inclusion in the files. -- Morbus Iff ( death to videodrome long live the new flesh ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
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!
Op maandag 12 december 2005 10:59, schreef Piotr Krukowiecki:
Why they should not be used in .mysql files? Because ignoranty users will use them Just Like That. And there is a big chance you delete very valuable data, while it is not needed at all.
-- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
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
Adrian, what you described, along with the field type concept in CCK, makes for a nice CCK 2.0 where the actual data can be normalized. Add to this a great AJAX in-browser graphical schema editor, relations and your views proposal, and we're getting pretty darn close to the system I've been hoping Drupal would become :-) -Robert Adrian Rossouw wrote:
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.
On 12 Dec 2005, at 8:34 PM, Robert Douglass wrote:
Adrian, what you described, along with the field type concept in CCK, makes for a nice CCK 2.0 where the actual data can be normalized. Add to this a great AJAX in-browser graphical schema editor, relations and your views proposal, and we're getting pretty darn close to the system I've been hoping Drupal would become :-) Yeah =)
I also think it might be useful for keeping different content tables for each supported language (perhaps). who needs rails when you have drupal 5.0 =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 12 Dec 2005, at 1:59 AM, Moshe Weitzman wrote:
someone started this trend years ago and it gets repeated like a parrot. don't be a parrot. thanks.
We can now have install files for all contrib modules with upgrade information btw. I haven't seen it documented anywhere though. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
We can now have install files for all contrib modules with upgrade information btw.
I haven't seen it documented anywhere though.
hook_update_N() is documented with the other hooks in contrib. It could use a page in the Module developer's handbook. -- Neil Drumm http://delocalizedham.com/
participants (9)
-
Adrian Rossouw -
Ber Kessels -
Morbus Iff -
Moshe Weitzman -
Neil Drumm -
piotr＠mallorn.ii.uj.edu.pl -
Robert Douglass -
Syscrusher -
Walt Daniels