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 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
>>>
>>
--
