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 :)
>
>
