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')
db.define_table('second_table', Field('field1'), Field('field2'))
db.second_table.field3 = Field.Method(lambda row: 'value for field3')
...then it would make no sense to use lazy_tables=True, because anyway I'm
calling both tables in the model, right?
If this is the case, is there any alternative to this?
I'm thinking to define a function in a module, the function would take the
row as an argument and return the value.
However, it wouldn't be possible to call the function in the "row.method"
way, but if it improves performance, I will do it that way.
I would appreciate any comment or advise on this, if any.
Thanks again!
El jueves, 17 de marzo de 2016, 14:42:48 (UTC-3), Anthony escribió:
>
> 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_me_data = Field.Method(lambda row: _give_me_data(row.
>> auth_user))
>>
>> def _give_me_data(user):
>> # calculation and obtention of data
>> # return data
>>
>> So first question: *should I move declaration of _give_me_data function
>> to a module?*
>> Or is it the same because I would have to import it anyway in the model?
>> *Just to remind, I'm using lazy_tables=False, so maybe the code isn't
>> really executed until the table is called. I'm not sure about this.*
>>
>
> Note, as soon as you do db.auth_user, the table is no longer lazy. Maybe
> not a big deal for this one table.
>
> Probably doesn't matter much where you define the function, though I
> suppose there could be a slight performance benefit to putting it in a
> module (where it will only be defined once instead of on every request).
>
>
>> *Usage of Storage class objects*
>> In my models, I create some Storage objects, because it's really useful
>> for setting and retrieving data from those objects. I use them like this:
>>
>> from gluon.tools import Storage
>>
>> CONFIG = Storage()
>> CONFIG.variable1 = 'value-variable-1'
>> CONFIG.variable2 = 'value-variable-2'
>>
>> I don't put much data inside them, just config variables.
>> However, my question is: *should I use other data type to storage those
>> variables?* Or it won't make any difference?
>>
>
> Again, probably not a big deal, but you could move that to a module, or
> maybe use AppConfig (which caches the configuration data after the initial
> setup).
>
> 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.
