Thanks for the suggestion. An autocomplete widget is a good alternative. On
further thought, and in keeping with the spirit of web2py, perhaps a
threshold based on the count of the number of records (say 100 rows) may be
used to determine if SQLFORM selects an options widget or autocomplete
widget by default. This would allow for more graceful degradation as the
real issue isn't so much setting up the field with a particular widget but
the time required to track down the problem...
On Tuesday, December 4, 2012 10:55:23 PM UTC+8, Massimo Di Pierro wrote:
>
> If the value of B.A comes from a A.id (represented by A.name) and you have
> 300,000 options, you probably do not want a dropdown but you want
> autocomplete. You just need:
>
> db.B.A.widget = SQLFORM.widgets.autocomplete(request, db.A.name, db.A.id)
>
> Massimo
>
> On Tuesday, 4 December 2012 01:03:39 UTC-6, onetwomany wrote:
>>
>> I have a table A that is referenced by another B using the standard
>> reference type in web2py.
>>
>> db.define_table('A',
>> ...
>> field('name')
>> ...
>> )
>>
>> db.define_table('B',
>> ...
>> field('A', db.A)
>> ...
>> )
>>
>>
>> Previously, everything was working fine but after importing a sizeable
>> amount of records (>300k rows) into table A, the app stalls when trying to
>> load a form generated by
>>
>> form = SQLFORM(db.B, record = x)
>>>
>>> Tracing the stall, I found that this occurred at the point where
>> SQLFORM tries to build the options widget and populate it with records from
>> table A. I have a modest server and hence, this problem may not be
>> noticeable at this scale for a more powerful server.
>>
>> The workaround I have managed to get working is to override the default
>> options widget with
>>
>> db.define_table('B',
>> ...
>> field('A', db.A, widget=SQLFORM.widgets.string.widget)
>> ...
>> )
>>
>> The question I have is if there is a better way to overcome this?
>>
>
--
