We can even use a set inside an IS_IN_DB() requires inside model definition
something like that prevent model from being lazy :
db.define_table('tablename',
Field('fk_id_field', 'reference othertable',
requires=IS_IN_DB(db(db.othertable.id
> 0), 'othertable.id', '%(represent_field)s')
)
)
This is sad...
I confirm that
some_set = db(db.tablename.fieldname > 1)
put in model outside of table definition prevent the table over which the
set point from being lazy...
And use of set inside IS_IN_DB() also prevent table from being lazy
:(
Richard
On Wed, Mar 15, 2017 at 12:24 AM, Richard Vézina <
[email protected]> wrote:
> Found couples other issue with IS_IN_DB() declarations in other
> controllers...
>
> But I use my own version of lazy_option (https://github.com/scubism/
> sqlabs/blob/master/controllers/plugin_lazy_options_widget.py) and the way
> field attribute has to be pass is another source of unlazy table...
>
> Except if refactor it, I guess the only other option is to move the
> requires in controller which is not wonderful as it split apart the
> models/validators definitions...
>
> I also use to define db set that I use in requires latter that way :
>
> some_set = db(db.tablename.fieldname > 1)
>
> But I am not sure if they are responsible for the unlazyness of the tables
> as it difficult to test properly because of the size of my app 150+ tables
> and multiples models files... Will make a test case...
>
> At least, I know where to look now, thanks to your help!
>
> Thanks Leonel
>
> Richard
>
>
>
> On Tue, Mar 14, 2017 at 4:55 PM, Richard Vézina <
> [email protected]> wrote:
>
>> My app predate auth.signature that why I am not using it, I would had to
>> refactor alot of table. But would be good to do it as I would have the
>> chance to harmonize, I sometimes don't use signature for less important
>> table and my custom signature fields names are not very "clean code" proof
>> or sure.
>>
>> Richard
>>
>> On Tue, Mar 14, 2017 at 4:50 PM, Richard Vézina <
>> [email protected]> wrote:
>>
>>> And there must be something else involve as in my app (not the dummy app
>>> I packaged) commenting the above not make the defined table become lazy as
>>> it does in not_lazy app...
>>>
>>> :(
>>>
>>> Richard
>>>
>>> On Tue, Mar 14, 2017 at 4:35 PM, Richard Vézina <
>>> [email protected]> wrote:
>>>
>>>> It seems related to as when I comment it all tables are lazy :
>>>>
>>>> db.auth_user._enable_record_versioning(archive_db=db,
>>>> archive_name='auth_user_archi
>>>> ve',
>>>> current_record='current_record',
>>>> is_active='is_active')
>>>>
>>>> So I guess you are right and it apply to all table even with this
>>>> syntax : db.tablename._enable_record_versioning(...)
>>>>
>>>> Richard
>>>>
>>>> On Tue, Mar 14, 2017 at 4:20 PM, Richard Vézina <
>>>> [email protected]> wrote:
>>>>
>>>>> As far as I can understand I am using it properly and not all the
>>>>> tables are versionned :
>>>>>
>>>>> http://web2py.com/books/default/chapter/29/06/the-database-a
>>>>> bstraction-layer#Record-versioning
>>>>>
>>>>> As I set it for auth_user only and not use .enable_record_versioning()
>>>>> but ._enable_record_versioning()... Can someone confirm that?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Richard
>>>>>
>>>>> On Tue, Mar 14, 2017 at 4:11 PM, Richard Vézina <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> About redefine auth tables, I don't know another way to set
>>>>>> username=True than :
>>>>>>
>>>>>> auth.define_tables(username=True)
>>>>>>
>>>>>> I had in my todo-list to refactor my code to use the new way of
>>>>>> customizing auth tables, maybe it would solve this issue if it really is
>>>>>> one??
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>> On Tue, Mar 14, 2017 at 3:55 PM, Richard Vézina <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Good catch for the IS_IN_DB() I wrote this part fast (address book
>>>>>>> part) long time ago in a pet app and copy the code in production without
>>>>>>> too much double check...
>>>>>>>
>>>>>>> I am not sure I understand why you say that I record versioning the
>>>>>>> whole tables as far as I understand this version only auth_user, no??
>>>>>>>
>>>>>>> db.auth_user._enable_record_versioning(archive_db=db,
>>>>>>>
>>>>>>> archive_name='auth_user_archive',
>>>>>>>
>>>>>>> current_record='current_record',
>>>>>>>
>>>>>>> is_active='is_active')
>>>>>>>
>>>>>>> Or you talk about another part of the code?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> Richard
>>>>>>>
>>>>>>> On Tue, Mar 14, 2017 at 3:42 PM, Richard Vézina <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Thanks for the look up... Too many questions at the same time, will
>>>>>>>> review my code base on your pin point...
>>>>>>>>
>>>>>>>> :)
>>>>>>>>
>>>>>>>> Richard
>>>>>>>>
>>>>>>>> On Tue, Mar 14, 2017 at 3:28 PM, Leonel Câmara <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Ok I've found the problem.
>>>>>>>>>
>>>>>>>>> You have 2 IS_IN_DB validator calls where you use db.address.id
>>>>>>>>> and db.phone_number_kind.id instead of "address.id" and "
>>>>>>>>> phone_number_kind.id"
>>>>>>>>>
>>>>>>>>> But the bigger problem is that you are enabling record versioning
>>>>>>>>> for all tables which pretty much makes them all load.
>>>>>>>>>
>>>>>>>>> Instead of this you can add an on_define to each table where you
>>>>>>>>> turn record versioning on for that specific table.
>>>>>>>>>
>>>>>>>>> def toggle_versioning(table):
>>>>>>>>> table._enable_record_versioning()
>>>>>>>>>
>>>>>>>>> db.define_table('my_versioned_table',
>>>>>>>>> Field('name'),
>>>>>>>>> on_define=toggle_versioning
>>>>>>>>> )
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By the way why are you defining auth tables in your model and then
>>>>>>>>> calling auth.define_tables to define them again, also consider using
>>>>>>>>> auth.signature instead of tables_generic_fields.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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 [email protected].
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
