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_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 there? Now you can do:
>
> def set_requirements(person): person.name.requires=IS_IN_SET(build_set())
> db.define_table('person',Field('name'),on_define=set_requirements)
>
> Notice that this does not call build_set() until the table is actually
> defined, moreover is does use the notation db.person and therefore does not
> force table instantiation.
>
>
>
>
>
>
>
>
>
>
> On Thursday, 23 August 2012 13:22:34 UTC-5, 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
>>> which has a huge traffic, so Lazy tables might be useful.
>>>
>>
>> No, I meant an example of where the new on_delete argument would be
>> useful.
>>
>> Anthony
>>
>
--
