Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed usage of field.choices that triggered full table load #8950

Merged
merged 1 commit into from
Jun 13, 2023

Conversation

lnagel
Copy link
Contributor

@lnagel lnagel commented Apr 17, 2023

Description

Removed the {{ field.choices|yesno:",disabled" }} block because this triggers the loading of full database table worth of objects just to determine whether the multi-select widget should be set as disabled or not.

Since this "disabled" marking feature is not present in the normal select field, then I propose to remove it also from the multi-select.

The reason why I found this was that HTML forms in the browsable API became extremely slow, but only when relation fields with many=True were being used.

Removed the `{{ field.choices|yesno:",disabled" }}` block because this triggers the loading of full database table worth of objects just to determine whether the multi-select widget should be set as disabled or not.

Since this "disabled" marking feature is not present in the normal select field, then I propose to remove it also from the multi-select.
@@ -11,7 +11,7 @@
{% endif %}

<div class="col-sm-10">
<select multiple {{ field.choices|yesno:",disabled" }} class="form-control" name="{{ field.name }}">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how can we determine this won't create any regression?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my side I will include the modified template in our current projects. So far this seems to have resolved the issue of forms not loading within 30 seconds that the application server is willing to wait on DRF request processing and the end user getting a gateway timeout.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another way to reason about this: as long as field.choices are present (field queryset is non-empty), then the select element is not assigned the "disabled" html attribute. Theoretically speaking it should not matter whether a multi-select field without any choices is disabled or enabled - there isn't anything to select.

Is anyone aware of some corner case situation that we should be aware of?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible to add test coverage for this?

@auvipy auvipy closed this Apr 19, 2023
@auvipy auvipy reopened this Apr 19, 2023
@auvipy auvipy requested a review from juspence April 20, 2023 04:08
@auvipy auvipy added this to the 3.15 milestone Jun 13, 2023
@auvipy auvipy merged commit 8333134 into encode:master Jun 13, 2023
auvipy added a commit that referenced this pull request Jun 17, 2023
* fix OpenAPIRenderer for timedelta

* added test for rendering openapi with timedelta

* fix OpenAPIRenderer for timedelta

* added test for rendering openapi with timedelta

* Removed usage of field.choices that triggered full table load (#8950)

Removed the `{{ field.choices|yesno:",disabled" }}` block because this triggers the loading of full database table worth of objects just to determine whether the multi-select widget should be set as disabled or not.

Since this "disabled" marking feature is not present in the normal select field, then I propose to remove it also from the multi-select.

* Added Deprecation Warnings for CoreAPI (#7519)

* Added Deprecation Warnings for CoreAPI

* Bumped removal to DRF315

* Update rest_framework/__init__.py

* Update rest_framework/filters.py

* Update rest_framework/filters.py

* Update tests/schemas/test_coreapi.py

* Update rest_framework/filters.py

* Update rest_framework/filters.py

* Update tests/schemas/test_coreapi.py

* Update tests/schemas/test_coreapi.py

* Update setup.cfg

* Update rest_framework/pagination.py

---------

Co-authored-by: Asif Saif Uddin <[email protected]>

* Update copy right timeline

* Fix NamespaceVersioning ignoring DEFAULT_VERSION on non-None namespaces (#7278)

* Fix the case where if the namespace is not None and there's no match,
  NamespaceVersioning always raises NotFound even if DEFAULT_VERSION
  is set or None is in ALLOWED_VERSIONS

* Add test cases

* fix OpenAPIRenderer for timedelta

* added test for rendering openapi with timedelta

* added testcase for rendering yaml with minvalidator for duration field (timedelta)

---------

Co-authored-by: Rizwan Shaikh <[email protected]>
Co-authored-by: Lenno Nagel <[email protected]>
Co-authored-by: David Smith <[email protected]>
Co-authored-by: Asif Saif Uddin <[email protected]>
Co-authored-by: Konstantin Kuchkov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants