ok, now it is as clear as crystal :)
thanks a lot guys. I appreciate your support
soon moving on to the most attractive part : "his Majesty the Scheduler"
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.
in addition (or just using different words of what Anthony said) ONLY when
you are in the web2py env in an HTTP request, web2py automatically commits
at the end of a successul request and rolls back if some exceptions are
raised, to ensure that EVERY operation you did for a request gets treated
not really. think a db.commit() as saving a file.
if you need to have something that does the 3 operations atomically (i.e.
either all three or none of them) you just commit() after the third one.
if you instead need to consolidate what op1 does in fear that what op2
might fail (and you don't w
ok i think i get it :
suppose I have a *scheduled task* that performs 3 successive *insert/update*
ops depending on each other like op2 might refer to op1 and op3 to op2 then
I must do:
op1 = db.tablea.insert_or_update(..)
db.commit()
some code here raises an exception
op2 = db.tableb.i
On Thursday, June 16, 2016 at 12:13:45 PM UTC-4, Pierre wrote:
>
> well, why would someone want to instantiate a web2py db connection outside
> of web2py (in a module) ?
>
There's no reason use of the DAL for database access should be limited to
HTTP requests. Not all database work involves web
well, why would someone want to instantiate a web2py db connection outside
of web2py (in a module) ?
I thought *current.db* is the standard way to access db from a module ?
So if the book doesn't refers to *current.db* speaking of
insert/update/delete ops in modules, I don't know what it refers t
What's written in the book is not worded well. Whenever database
modifications happen within a web2py HTTP request/response cycle, there is
no need to call db.commit(), no matter where the code is (it all gets
executed by the web2y framework, with web2py calling db.commit() itself
just before r
I think if you use the thread instance of db, i.e.
current.db
or
db tnasferred through parameter
i.e. db which was created in model,
then you don't need commit because such db will be commited with success of
the model-controller-view code.
But if db is instantiated in the module, outside from We
8 matches
Mail list logo