This was the error:
File "C:/web2py/applications/crm/models/db.py" <http://localhost:8080/admin/default/edit/crm/models/db.py>, line 85, in <module> session.setdefault("history", []) TypeError: 'NoneType' object is not callable However now I get a different error in latest trunk: File "C:/web2py/applications/crm/models/dbtables.py" <http://localhost:8080/admin/default/edit/crm/models/dbtables.py>, line 65, in <module> format=lambda r: A(r.name, _href=URL(c='customer', f='singleview.html', args=(r.id)))) File "C:\web2py\gluon\dal.py", line 6934, in define_table table = self.lazy_define_table(tablename,*fields,**args) File "C:\web2py\gluon\dal.py", line 6945, in lazy_define_table fields = fields + self._common_fields TypeError: can only concatenate tuple (not "list") to tuple On Tuesday, 21 August 2012 14:04:26 UTC+1, Massimo Di Pierro wrote: > > What does not work? The new store has for now been reverted. > > On Tuesday, 21 August 2012 05:07:32 UTC-5, simon wrote: >> >> This line does not seem to work in latest trunk. Is that because of the >> new Storage object? >> >> session.setdefault("history", []) >> >> On Saturday, 18 August 2012 04:00:44 UTC+1, Massimo Di Pierro wrote: >>> >>> There are two major speed improvements in trunk and I am not sure >>> whether they should go in web2py 2.0 next week. >>> >>> 1) Lazy table (based on ideas from Bruno). >>> >>> db = DAL(...., lazy_tables=True) >>> db.define_table('person',Field('name')) >>> >>> the table is instantiated only when db.person is accessed. >>> So with some care: >>> >>> Field(...., requires=....) # LAZY (good) >>> db.table.field.requires = ... # NOT LAZY (bad) >>> >>> Field('other','reference table') # LAZY (good) >>> Field('other',db.table) # NOT LAZY (bad) >>> >>> this may be a big speedup. >>> >>> >>> 2) There is a new implementation of class Storage. This is a most >>> accessed object within web2py and now it is 10x faster. >>> Yet I am not sure if this breaks something. >>> >>> >>> It would be great if you could try the nightly build (or trunk) and >>> report if you experienced any problem. >>> It would be even better if you could run some benchmarks of your code >>> before and after the changes suggested at 1). >>> >>> Massimo >>> >>> >>> >>> >>> >>> --
