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

Reply via email to