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'm wondering about:
In my model, I have several tables (lets say about 8 or 9) that are used
to store information about list of options.
These tables only have a few records each, and they will never grow.
For example, one table could be "days" (I don't have this table
specifically, it's for the example).
So, let's say the table "days" has a "name" field and a "plural_name" field.
The table is populated with data only once, at application startup, and
remains the same forever: "days" table will only have 7 records, one for
each day of the week.
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]
WEDNESDAY = db.days[3]
THURSDAY = db.days[4]
FRIDAY = db.days[5]
SATURDAY = db.days[6]
SUNDAY = db.days[7]
I use that to be able to reference each day from the app code, but I've
realised that in this way, the "days" table won't be lazy, because it's
called to get the record.
So my question is: *what would be the correct approach for storing that
kind of records in variables, without compromising lazy tables?*
I've thouth of an answer myself, but I'm not sure.
One possible approach would be to define Storage objects instead of
pointing to the records.
Because I already know the data of the days table, I can replace the
previous code with this:
from gluon.tools import Storage
MONDAY = Storage()
MONDAY.id = 1
MONDAY.name = 'monday'
MONDAY.plural_name = 'mondays'
*Would it be better in terms of performance?*
Of course, I wouldn't have methods available at the row level, but I don't
use them in this case.
El jueves, 17 de marzo de 2016, 20:17:49 (UTC-3), Anthony escribió:
>
> 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('mytable', Field('field1'), Field('field2')) # defines
>> the table
>> from myglobals import myfunction # imports global function
>> db.mytable._after_update.append(lambda s, r: myfunction(s, r)) #
>> defines after update callback trigger
>>
>> In this case, I guess lazy_tables=True wouldn't make sense, because I'm
>> calling db.mytable so it triggers the definition of the table.
>>
>> Is there a way of specifying callback triggers directly when calling
>> define_table?
>>
>>
>>
>>
>> El jueves, 17 de marzo de 2016, 15:27:22 (UTC-3), Lisandro escribió:
>>>
>>> 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, 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 wouldn't make sense to use lazy_tables in a particular case where
>>>>> almost
>>>>> each table has a virtual method field, am I right?*
>>>>>
>>>>> I mean, for example, if this is my model:
>>>>>
>>>>> db.define_table('first_table', Field('field1'), Field('field2'))
>>>>>
>>>>> db.first_table.field3 = Field.Method(lambda row: 'value for field3')
>>>>>
>>>>
>>>> This won't help with db.auth_user, which is defined automatically
>>>> (though you can define it manually yourself if preferred), but you can
>>>> simply do:
>>>>
>>>> db.define_table('first_table',
>>>> Field('field1'),
>>>> Field('field2'),
>>>> Field.Method('Field3', lambda row: 'value for field3'))
>>>>
>>>> Note, the first argument of Field.Method() and Field.Virtual() should
>>>> always be the field name anyway, even if you are defining them like this:
>>>>
>>>> db.mytable.myfield = Field.Method('myfield', ...)
>>>>
>>>> There are particular cases where leaving the name out can lead to
>>>> problems.
>>>>
>>>> Anthony
>>>>
>>>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
