[web2py] Re: Optimizing web2py app for GAE
Let us say I have the below code in db.py under models define_table(db, ) If I change that to, if settings.migrate: define_table(db,...) rest of the queries based on this table doesn't work. I want to skip the definition altogether if the table is already present. Reason: I assume that GAE makes a datastore call for each of these define_table. So every page request initiates these define_table adding to the cost of datastore read limits posed in GAE. Is this how it happens? Can I skip definition of tables altogether? (I believe django doesn't invoke definition of tables for every request) Objective is to optimize application on GAE. Thank you, Joseph
[web2py] Re: Optimizing web2py app for GAE
On Friday, December 30, 2011 4:22:29 AM UTC-5, Joseph Jude wrote: Let us say I have the below code in db.py under models define_table(db, ) If I change that to, if settings.migrate: define_table(db,...) rest of the queries based on this table doesn't work. I want to skip the definition altogether if the table is already present. Reason: I assume that GAE makes a datastore call for each of these define_table. So every page request initiates these define_table adding to the cost of datastore read limits posed in GAE. Is this how it happens? Can I skip definition of tables altogether? (I believe django doesn't invoke definition of tables for every request) The table definition creates the table model for web2py to use, so you cannot skip the table definition if your application code needs to do anything with that table model during the request. I don't think merely calling define_table should result in a datastore hit (I'm not totally sure about that on GAE, but in non-GAE environments, define_table won't touch the db, unless it results in a migration happening). I'm not sure why you have so many reads. Maybe check to see if you're doing any recursive selects: http://web2py.com/books/default/chapter/29/6#Recursive-selects. Anthony
[web2py] Re: Optimizing web2py app for GAE
You have to do:
db.define_table('name',...,migrate=settings.migrate)
The table has to be defined because web2py needs to know how to map
SQL types into web2py types. The migrate argument, when set to False,
will prevent the CREATE TABLE. Anyway, web2py does not CREATE
TABLE if it exists already.
Massimo
On Dec 30, 3:22 am, Joseph Jude ceph...@gmail.com wrote:
Let us say I have the below code in db.py under models
define_table(db, )
If I change that to,
if settings.migrate:
define_table(db,...)
rest of the queries based on this table doesn't work. I want to skip the
definition altogether if the table is already present. Reason: I assume
that GAE makes a datastore call for each of these define_table. So every
page request initiates these define_table adding to the cost of datastore
read limits posed in GAE. Is this how it happens? Can I skip definition of
tables altogether? (I believe django doesn't invoke definition of tables
for every request)
Objective is to optimize application on GAE.
Thank you,
Joseph
[web2py] Re: Optimizing web2py app for GAE
On Friday, December 30, 2011 11:25:51 AM UTC-5, Massimo Di Pierro wrote:
You have to do:
db.define_table('name',...,migrate=settings.migrate)
The table has to be defined because web2py needs to know how to map
SQL types into web2py types. The migrate argument, when set to False,
will prevent the CREATE TABLE. Anyway, web2py does not CREATE
TABLE if it exists already.
Looks like create_table is called regardless of migrate on GAE:
if migrate or self._adapter.dbengine=='google:datastore':
try:
sql_locker.acquire()
self._adapter.create_table(t,migrate=migrate,
fake_migrate=fake_migrate,
polymodel=polymodel)
GoogleDatastoreAdapter.create_table() itself doesn't seem to do anything
with 'migrate', but not clear if it results in any datastore activity.
Looks like it just creates a gae.Model object:
if not polymodel:
table._tableobj = classobj(table._tablename, (gae.Model, ), myfields)
Anthony
[web2py] Re: Optimizing web2py app for GAE
Perhaps these links will help: http://groups.google.com/group/google-appengine/browse_thread/thread/21478bd9185dcc32/f61b532da5c46588?lnk=gstq=index+reads#f61b532da5c46588 http://groups.google.com/group/google-appengine/browse_thread/thread/bdb45e04dd8f959e/0659767c7878bafb?lnk=gstq=index+reads#0659767c7878bafb http://groups.google.com/group/google-appengine/browse_thread/thread/fef4a4c22a50039/4ae7426d4daca9d2?lnk=gstq=index+reads#4ae7426d4daca9d2 So, excessive index reads could be a problem...
