ah... I didn't see your reply... so, i don't think I want to start the app from scratch but rather restart the build process just delete unused table (specially if a table exists because of previous trial runs).
Here's the logic: * there is a build system. I made it to let some users configure and kick off builds of their applications themselves (not the type of builds to go to something like a nightly build process - they a very much customer focused software builds). * so, to keep things as transparent as possible (like a black box), I set it up so it feels like an afternoon of shopping: "I'll take a couple of those , and a few of these, etc..." - so they have no clue of what is happening (which is a very good thing sometimes ;) ). * they are basically creating functions which get wrapped up in a class module, which then gets dynamically __imported__. When It gets loaded, the build system is fooled in thinking that the new-module already exists (since the new module inherits the baseClass and uses its already available pool of data)... so here is why it is important to somewhat start from scratch, but not really... the db is put to use for 2 things 1) store build reports, activity, logging, etc... and 2) - you actually provided the idea with plugin_wiki where the code lives in the DB ;)) - builds are customizable, today a build may looks like THIS, tomorrow another one will be defined looking like THAT, etc. Since the DB will tell the complete tale (which is a huge customer requirements that all builds be reproducible, exact as they were), the data describing the build can not be flawed. So as the user defines his build with the help of menu items, check boxes and soon drag&drop features, it becomes very much an expectation that "new module" tables get generated and deleted continuously... so, from scratch, but not really... only part the the build definition is recreated from scratch and I don't want to give them any reason to be confused and make them doubt the build data (we get their doubtful nature for free :) )... make any sense? so, how to programmatically (<-- that may not actually be a real word :) ) delete, every trace, the stuff you mention below ? thanks On Oct 18, 11:07 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > If you really need to restart an app from scratch and you use sqlite, > you can sply delete everyting under > - databases > - uploads > - cache > - sessions > - errors > > On Oct 18, 9:59 am, ron_m <ron.mco...@gmail.com> wrote: > > >http://web2py.com/book/default/chapter/06?search=drop#drop > > > db.table_name.drop() > > > Ron > > > On Oct 18, 7:40 am, mart <msenecal...@gmail.com> wrote: > > > > Hi, > > > > does anybody know how to delete a table using dal.py? I need to > > > provide users with the choice of starting a process from scratch (and > > > over and over again until satisfied). Which means on the first go, a > > > user who is defining some steps in a software build setup, may be > > > configuring, let' call call it step_E, which cause a table to be > > > created @ runtime. Then as the user is continuing to setup and tweak > > > his build setup, he may decide that step_F is better suited. Since > > > these tables are created on the fly and that step_E is being replaced > > > with step_F, the step_E table needs to disappear. So, is their a way > > > to not just drop the records, but he entire table it self? if not when > > > all tables get delivered as part of the overall build reports, then > > > the testers will look at the contents and see an empty container (the > > > step_E table)... from experience, this type of confusion never, ever, > > > goes away. so to have a method to look at the set of generated tables, > > > and remove those not listed is the best remedy. > > > > And, if I tell them to blow away the entire staging area and start > > > over, there will be some panic ;) So, we keep the good tables where we > > > don't update/insert if nothing new and delete the bad tables... Can > > > anyone help? > > > > Again,any help is appreciated, > > > > Thanks, > > > Mart :) > >
