Django-rest-framework: Ui takes too much time to load for models that have foreign keys to other models with many entries

Created on 25 Apr 2016  路  5Comments  路  Source: encode/django-rest-framework

Checklist

  • [ ] I have verified that that issue exists against the master branch of Django REST framework.
  • [x] I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
  • [x] This is not a usage question. (Those should be directed to the discussion group instead.)
  • [x] This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
  • [x] I have reduced the issue to the simplest possible case.
  • [ ] I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

    Steps to reproduce

Create A, B and C models. A has foreign keys to B and C. B and C both have millions of entries. Access the API UI for model A. Even without any data, the UI will take huge time to load, has it is populating the dropdowns for choosing the foreign keys with all instances of B and C.

Expected behavior

Load immediately. Possibly use an asynchronous search when choosing a value for the foreign keys over the respective models.

Actual behavior

Loading the UI for the model in the API takes huge amount of time.

Most helpful comment

A way to fix this is in the documentation http://www.django-rest-framework.org/api-guide/relations/#select-field-cutoffs

Using base_template just doesn't render the dropdown.

All 5 comments

A way to fix this is in the documentation http://www.django-rest-framework.org/api-guide/relations/#select-field-cutoffs

Using base_template just doesn't render the dropdown.

I think this should be a automatic. Either when more than 20 (or other small number) rows exist in the referenced entity or every time, the dropdown should become a search box and queries for the referenced model would be paginated by default. This will ease adoption of the framework and prevent more people to come here with the same issue.

@tiagoboldt you'll get the same issue in the Django admin or with pure Django forms as well.
This use case requires some understanding. Adding a search box that does not have the content preloaded will make things way harder to DRF 'cause the browsable API will have to set new urls and entry points behind the scene, possibly allowing information leaks.
Closing it in the current form, will reconsider with a more actionable issue.

Could we add a setting to just turn off the filter form like in https://github.com/tomchristie/django-rest-framework/issues/4071 ?

Overriding the BrowsableAPIRenderer's get_filter_form seems the way to go to me and won't require much work.

Was this page helpful?
0 / 5 - 0 ratings