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=30),
])
and the attributes will be set lazily. This is a good idea! Thanks Jonathan.
On Monday, 20 August 2012 16:36:22 UTC-5, Jonathan Lundell wrote:
>
> On 20 Aug 2012, at 10:32 AM, Massimo Di Pierro
> <[email protected]<javascript:>>
> 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 <[email protected]>
> 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.
> >
>
>
>
--
