Fix 500 on unintended endpoints and further refactor association router #370
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
john-westcott-iv
changed the title
AlanCoding
changed the title
AlanCoding
added
the
Ready for review
|
I've created #393 to discuss 2 remaining things I'm still not happy with. But I don't want those in scope here. |
AlanCoding
commented
May 16, 2024
|
@AlanCoding to make a merge meeting for this PR sometime next week. |
AlanCoding
force-pushed
the
only_list2
branch
2 times, most recently
from
ecdfb87
to
391e703
Compare
AlanCoding
commented
May 21, 2024
relrod
approved these changes
May 21, 2024
|
AlanCoding
added a commit
that referenced
this pull request
May 23, 2024
I only just merged #370 but this fixes a problem with it. This was encountered using drf-spectacular decorators to resolve very boutique eda-server issues, which could result in the traceback: ``` File "/home/alancoding/venvs/eda/lib64/python3.11/site-packages/drf_spectacular/drainage.py", line 168, in get_view_method_names return [ ^ File "/home/alancoding/venvs/eda/lib64/python3.11/site-packages/drf_spectacular/drainage.py", line 169, in <listcomp> item for item in dir(view) if callable(getattr(view, item)) and ( ^^^^^^^^^^^^^^^^^^^ File "/home/alancoding/repos/awx/testing/django-ansible-base/ansible_base/lib/routers/association_resource_router.py", line 231, in attribute_raiser raise AttributeError AttributeError ``` This traceback is a problem even when you have no other context. You can see `item for item in dir(view)`. Then one of those items gives an `AttributeError`. I mean, the `dir` method is pretty much, by definition, the set of attributes that won't give you an attribute error. Non-obvious, but since all of this is done inspecting the view _class_, similar to the AttributeError, all the fixes have to be done on the metacalss.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Something drove me crazy after testing with my last patch - which is that certain serializers (with the same name) were created twice. This is logical if you think about what's being done. This PR adds a registry to fix the problem.
It also trades a few things in code organization. It gets rid of the "factory" method, and adds a new utility method for getting the parent class, which has to follow a certain format. Then the registry management becomes the main job of
get_serializer_classRecapping of major changes being done here:
visible_usersand the generalaccess_qscall in favor of calls tofilter_queryset.get_serializer_classno longer builds querysets (forinstances). This changes it to use methods from the view instance inside of the serializer context. This has to happen on the serializer__init__.get_querysetas the listing does, which only includes attached objects to begin with.