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 caller-defined on_define function can do things like:
def on_define(table):
table.field.readable = True
or, more interestingly:
def on_define(table):
if request.something == whatever:
table.field.readable = True
...etc. Assuming that there's dynamic stuff like that going on, it saves having
to figure out whether you're in a request in which the table is going to be
instantiated and then modify the fields.
One more thought, just an abstract one because I don't have an example to
offer. Since we're storing args at define_table time, to be used later when the
table is referenced, it's important that the caller not include mutable objects
in args and change them (in relevant ways) between the define_table call and
the instantiation.
>
> 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.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.
>>
>
> Here's a vague idea: suppose define_table had a requirements parameter,
> defaulting to None, that could be set to a function (lambda or otherwise)
> that would be called after the table is instantiated? Then you'd still be
> able to pull your dynamic requirements into one place, but without triggering
> define-time instantiation. For convenience, the function would be called for
> any instantiation, even a non-lazy one, so one could turn lazy instantiation
> on & off for testing without changing it.
>
--
