On Thursday, March 17, 2016 at 1:53:43 PM UTC-4, Lisandro wrote:
>
> Thank you very much for the quick answer.
>
> Your first comment made me think about the "lazy_tables" with the
> definition of virtual method fields.
> If you say that doing db.tablename the table is no longer lazy, *then it
>
I will bother with one last related question: *what about callback
triggers?*
I'm defining them like this:
db.define_table('mytable', Field('field1'), Field('field2')) # defines the
table
from myglobals import myfunction # imports global function
db.mytable._after_update.append(lambda s, r: my
On Thursday, March 17, 2016 at 1:08:49 PM UTC-4, Lisandro wrote:
>
> Straight to the point:
> I'm using *lazy_tables=True* and *migrate=False*
>
>
> *In my model, I have several Method Fields.*
> Some of them use a function that is declared inside the same model, like
> this:
>
> db.auth_user.give
On Friday, March 18, 2016 at 10:19:40 AM UTC-7, Lisandro wrote:
>
> Anthony, thank you very much for your help.
>
> [...]
> I'm tempted to ask one more thing that I'm wondering about:
>
> In my model, I have several tables (lets say about 8 or 9) that are used
> to store information about li
See
http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer#on_define.
On Thursday, March 17, 2016 at 6:13:35 PM UTC-4, Lisandro wrote:
>
> I will bother with one last related question: *what about callback
> triggers?*
> I'm defining them like this:
>
> db.define_table('myt
Oh I see! So I can define the virtual/method fields that way, and then it
does make sense to keep using lazy_tables. Completely missed that point.
Thank you very much!
As always, web2py's community rocks.
El jueves, 17 de marzo de 2016, 14:59:35 (UTC-3), Anthony escribió:
>
> On Thursday, Ma
Anthony, thank you very much for your help.
I've successfully changed the definition of the callback trigger, like this:
db.define_table('mytable',
Field('myfield'),
on_define=lambda table: table._after_update.append(lambda s, r: myfunction
(s, r))
)
I'm tempted to ask one more thing that I
Thank you very much for the quick answer.
Your first comment made me think about the "lazy_tables" with the
definition of virtual method fields.
If you say that doing db.tablename the table is no longer lazy, *then it
wouldn't make sense to use lazy_tables in a particular case where almost
each
On Friday, March 18, 2016 at 1:19:40 PM UTC-4, Lisandro wrote:
>
>
> Now, the part that I'm worried about is this: *inside the same model, I
> store each record in a variable*, like this:
>
> db.define_table('days', Field('name'), Field('plural_name'))
>
> MONDAY = db.days[1]
> TUESDAY = db.days[2
9 matches
Mail list logo
