Possible Issue, this might be due to the dal changes (or it could be me?):
I'm running a variation of Bruno's Modelless App (and I tried his out of
the box) https://github.com/rochacbruno/web2py_model_less_app
, and I get:
AttributeError: 'DataBase' object has no attribute '_LAZY_TABLES'
On
To solve this issue include in the line 88 of myapp.py
https://github.com/rochacbruno/web2py_model_less_app/blob/master/modules/myapp.py#L88
self._LAZY_TABLES = []
On Mon, Aug 27, 2012 at 11:33 PM, Andrew awillima...@gmail.com wrote:
Possible Issue, this might be due to the dal changes (or
Thanks very much for a quick response,
and add the next line too :
self._LAZY_TABLES = []
self._tables = []
On Tuesday, August 28, 2012 2:53:01 PM UTC+12, rochacbruno wrote:
To solve this issue include in the line 88 of myapp.py
On 23 Aug 2012, at 7:25 AM, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
So now in trunk you can do:
db = DAL(lazy_tables=True)
db.define_table('person',Field('name'),Field('age','integer'),
on_define=lambda table: [
Exactly.
mytable.myfield.set_attributes(readable=True,writable=True)
is just a shortcut for
mytable.myfield.readable=True
mytable.myfield.writable=True
without it the lambda notation would not be very usable.
On Saturday, 25 August 2012 11:50:10 UTC-5, Jonathan Lundell wrote:
On
So now in trunk you can do:
db = DAL(lazy_tables=True)
db.define_table('person',Field('name'),Field('age','integer'),
on_define=lambda table: [
table.name.set_attributes(requires=IS_NOT_EMPTY(),default=''),
db = DAL(lazy_tables=True)
db.define_table('person',Field('name'),Field('age','integer'),
on_define=lambda table: [
table.name.set_attributes(requires=IS_NOT_EMPTY(),default=''),
table.age.set_attributes(requires=IS_INT_IN_RANGE(0,120),default=30),
])
and the
On 23 Aug 2012, at 7:48 AM, Anthony abasta...@gmail.com wrote:
db = DAL(lazy_tables=True)
db.define_table('person',Field('name'),Field('age','integer'),
on_define=lambda table: [
table.name.set_attributes(requires=IS_NOT_EMPTY(),default=''),
Couple of things (including questions).
1. attributes defined in the Field() spec are lazy already, right?
I guess not so much lazy, but for the most part all that happens is they
get added as attributes to the Field's self. There is a little logic in the
constructor, though. I suppose
On 23 Aug 2012, at 8:39 AM, Anthony abasta...@gmail.com wrote:
Couple of things (including questions).
1. attributes defined in the Field() spec are lazy already, right?
I guess not so much lazy, but for the most part all that happens is they
get added as attributes to the Field's self.
Isn't that what my code does?
In the example I used a lambda instead of a function but the implementation
should be exactly what you say. Perhaps I misunderstood.
BTW. Auth is now fully lazy, when DAL(lazy_tables=True), and therefore
should be faster. Needs testing and benchmarking.
massimo
On 23 Aug 2012, at 9:16 AM, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
Isn't that what my code does?
In the example I used a lambda instead of a function but the implementation
should be exactly what you say. Perhaps I misunderstood.
Or maybe I did. I'll have a chance to look at
I'd also still be interested to see a real-world example of where this
would be useful.
Anthony
On Thursday, August 23, 2012 12:19:24 PM UTC-4, Jonathan Lundell wrote:
On 23 Aug 2012, at 9:16 AM, Massimo Di Pierro
massimo@gmail.comjavascript:
wrote:
Isn't that what my code does?
On Thu, Aug 23, 2012 at 3:11 PM, Anthony abasta...@gmail.com wrote:
I'd also still be interested to see a real-world example of where this
would be useful.
Anthony
Someone posted an example of GAE CPU Cycles, with class based Lazy Tables
it lower to half cycles. Also there is another user
I'd also still be interested to see a real-world example of where this
would be useful.
Anthony
Someone posted an example of GAE CPU Cycles, with class based Lazy Tables
it lower to half cycles. Also there is another user in the group which has
a huge traffic, so Lazy tables might be
Here is an example:
Say you have
db.define_table('person',Field('name'))
db.person.name.requires=IS_IN_SET(build_set())
where build_set is computationally expensive. You only want to create the
set if you actually need the table. You can move it in the controller
action but does it belong
OK, that makes sense. I guess there's no good way to make that lazy at the
Field level.
Thanks.
Anthony
On Thursday, August 23, 2012 4:10:23 PM UTC-4, Massimo Di Pierro wrote:
Here is an example:
Say you have
db.define_table('person',Field('name'))
No without making non-lazy table significatively slower.
On Thursday, 23 August 2012 15:32:08 UTC-5, Anthony wrote:
OK, that makes sense. I guess there's no good way to make that lazy at the
Field level.
Thanks.
Anthony
On Thursday, August 23, 2012 4:10:23 PM UTC-4, Massimo Di Pierro
On 18 Aug 2012, at 1:46 PM, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
As Bruno says. Something like this will completely nullify the benefit of
lazy tables.
Field(..., readable=True) is OK but
db.table.field.readable=True is BAD because will force db.table to be
instantiated.
can you show a proof of concept?
On Monday, 20 August 2012 11:51:27 UTC-5, Jonathan Lundell wrote:
On 18 Aug 2012, at 1:46 PM, Massimo Di Pierro
massimo@gmail.comjavascript:
wrote:
As Bruno says. Something like this will completely nullify the benefit of
lazy tables.
Field(...,
On 20 Aug 2012, at 10:32 AM, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
can you show a proof of concept?
Not exactly a proof, but a concept.
At the very end of lazy_define_table, just before 'return table':
if args.get('on_define'):
args.get('on_define')(table)
The
How is this different than
Field(...readable=True)
You still have to put the readable=True somewhere. Why put it in a callback
(ondefine) instead of where it belongs?
On Monday, 20 August 2012 16:36:22 UTC-5, Jonathan Lundell wrote:
On 20 Aug 2012, at 10:32 AM, Massimo Di Pierro
On 20 Aug 2012, at 8:22 PM, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
How is this different than
Field(...readable=True)
You still have to put the readable=True somewhere. Why put it in a callback
(ondefine) instead of where it belongs?
It's not necessary in this example. I
I suppose something like this would be more useful if you could register
the on_define sometime after the initial table definition. For example, you
might want to add some custom validators to some db.auth_user fields after
calling auth.define_tables(). In that case, you might do something
Maybe it might be helpful to call this concept lazy models?
After all, you can put all the requirements you like in
controllers/functions; you wouldn't be concerned about lazy models at that
point.
On Tuesday, August 21, 2012 4:37:33 AM UTC+1, Jonathan Lundell wrote:
On 20 Aug 2012, at
nice to hear this, I'm going to test it.
2012/8/18 Massimo Di Pierro massimo.dipie...@gmail.com
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)
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
27 matches
Mail list logo
