oh.. well that is pretty much straight forward. I may be have been over thinking this.
Fantanstic! thanks for the help! Mart :) On Oct 18, 12:41 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > def cleanup(app): > import os > for sub in > ['databases','cache','sessions','tickets','errors','uploads']: > path=os.path.join(request.folder,'..',app,sub) > for file in os.listdir(path): > os.unlink(os.path.join(path,file)) > > On Oct 18, 11:18 am, mart <msenecal...@gmail.com> wrote: > > > 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 :) > >
