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
>
>
> https://github.com/rochacbruno/web2py_m
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 wrote:
> Possible Issue, this might be due to the dal changes (or it could be me?):
>
>
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
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
On 23 Aug 2012, at 7:25 AM, Massimo Di Pierro
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: [
>table.name.set_attributes(requires=IS_NOT_EMPTY(),default=''),
>
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 P
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'))
> db.person.name.requires=IS_IN_SE
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 ther
>
> 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 ta
On Thu, Aug 23, 2012 at 3:11 PM, Anthony 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 in the group whi
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
> >
> wrote:
>
> Isn't that what my code does?
>
> In the example I used a l
On 23 Aug 2012, at 9:16 AM, Massimo Di Pierro
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 it more closely later. L
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 8:39 AM, Anthony 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. There is a li
>
> 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 sup
On 23 Aug 2012, at 7:48 AM, Anthony 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=''),
>
> table.age.set_attributes(requires=IS_I
>
> 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),
> ])
>
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=''),
table.age.set_attributes(requires=IS_INT_IN_RANGE(0,120),default=
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,
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 like:
On 20 Aug 2012, at 8:22 PM, Massimo Di Pierro
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 use stuff like that wh
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
> >
> wr
On 20 Aug 2012, at 10:32 AM, Massimo Di Pierro
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 caller-defined on_define functi
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
> >
> wrote:
>
> As Bruno says. Something like this will completely nullify the benefit of
> lazy tables.
>
> Field(..., readable=True) is OK but
On 18 Aug 2012, at 1:46 PM, Massimo Di Pierro
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.
>
Here's a vague ide
nice to hear this, I'm going to test it.
2012/8/18 Massimo Di Pierro
> 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
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 w
27 matches
Mail list logo
