Yes, the data is there.
On Jan 31, 9:26 pm, mart <msenecal...@gmail.com> wrote: > i see... so, if I understand, only the table definitions are missing > (and I should know this), but I am hoping that this means just the > tables,not the data? If something Commet could make that the tabel > data available (maybe as a string), would it be possible to to : > > tables please? > client -----------------------------> web2py Server (commet > listener?) > > <------------------------------------ return "Models" as a > string (I don't know the tornado size limitations) > > Now that I have the the model, i should be able to have that explicite > define (with no data in the tables), then do dbRemote = DAL(... ? Or > maybe, this is silly... > > Maybe export/import is the best known solution? > > Thanks, > > mart :) > > On Jan 31, 9:09 pm, Massimo Di Pierro <massimo.dipie...@gmail.com> > wrote: > > > > > > > > > I see what you mean now. No you cannot do that. > > > If you do > > > python web2py.py -A app -M -N -R script.py > > > the script will be executed in an environment similar to a controller > > and will see the stuff defined in the models. > > > There is no way (currently) for you to do db=DAL(...) and have > > db.yourtable without an explicit db.define_table(..). > > > On Jan 31, 7:20 pm, mart <msenecal...@gmail.com> wrote: > > > > yes... that's what I meant... models ;) the models are invisible > > > > Thanks for that, I'll try that :) so with that, I can do something > > > like: > > > > dbRemote = DAL(.... > > > > ? > > > > Mart :) > > > > On Jan 31, 3:47 pm, Massimo Di Pierro <massimo.dipie...@gmail.com> > > > wrote: > > > > > Not sure what you mean by invisible. web2py does not learn about > > > > tables from the db. It learns about them from the models. > > > > > If you run a script with > > > > > python web2py.py -A app -M -N -R script.py > > > > > the script will see the models. > > > > > On Jan 31, 10:27 am, mart <msenecal...@gmail.com> wrote: > > > > > > right... ok, I get that. > > > > > > So, is there a way to connect a new network connection to an existing > > > > > sqlite db? I tried some suggestion from a posting of a few weeks ago, > > > > > and it seems to connect, but tables are 'invisible'. > > > > > > ** Note ** > > > > > some dbs are created from script (no web), still web2py (just no web, > > > > > like __2py ;)) and others are created/maintained in a deployed web2py > > > > > environment. Possible? can I for example have a script (DAL stand- > > > > > alone), connect to a fully deployed web2py's DB? Actually, the > > > > > scenario can be web2py app connects to another web2py app (on the same > > > > > or different server), can also be stand alone DAL to stand-alone DAL, > > > > > or stand-alone-DAL to web2py server, or web2py server to stand-alone > > > > > DALs db.... > > > > > > Thanks, > > > > > Mart:) > > > > > > On Jan 31, 9:24 am, Massimo Di Pierro <massimo.dipie...@gmail.com> > > > > > wrote: > > > > > > > Impossible. You cannot picke a network connection. It more than just > > > > > > data. > > > > > > > On Jan 31, 5:30 am, mart <msenecal...@gmail.com> wrote: > > > > > > > > Hi, > > > > > > > > I'm looking to try something (again) that has not yet been too > > > > > > > successful (but I still want to try)... Currently (with > > > > > > > stand-alone > > > > > > > Dal) I am managing by passing 'db' around (or rather self.db) to > > > > > > > avoid > > > > > > > having to create more instances than I have to. Now, to pick up > > > > > > > some > > > > > > > processes where they left off, I would like to try pickling > > > > > > > 'self.db' > > > > > > > to a file, let sys.exit() happen, load the pickle, then debug > > > > > > > exceptions, but without having to start from scratch ad rely on > > > > > > > breakpoints to wake me up when I get to troublesome areas (the > > > > > > > wait > > > > > > > can be as long as an hour sometimes). > > > > > > > > So, has anyone successfully pickled 'db'? Anything fancy that > > > > > > > need to > > > > > > > be done the the attributes (even if only temporary). > > > > > > > > Thanks, > > > > > > > Mart :)
