in order:
@alex: same thing. if you can stuff everything inside the define_table()
call you'll be sure to have everything working in the speediest way with
lazy_tables.
@richard: if you put a requires in the controller, the second that line is
executed, the table is unlazyed. The whole point of the thread should
obviously "fenced" into the scenario *what can I do to speedup model
execution, since the controller function is executed anyway*.
@rod: same thing.
<tl;dr> for everybody: tables stay lazy until someone does db.tablename.
Pythonicly-speaking, the getattr(tablename) on "db" triggers the
unlazyification.
<tl;dr> for evertbody, part two. the toolbar (response.toolbar()) has a
nice section that lists lazy and non-lazy tables. Checking if your models
are "in order" just takes three simple steps:
- create a fresh controller, i.e. controllers/testlazy.py
- create a test function in that controller, i.e.
def does_nothing():
return dict()
- hit appname/testlazy/does_nothing: by default the generic view shows the
toolbar. If you have all the tables listed as lazy you did a goo job. If
not, inspect your app to find any db.tablename call.
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
