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

ViewSet inheritance issue #218

Closed
konkab opened this issue Nov 30, 2020 · 7 comments · Fixed by #554
Closed

ViewSet inheritance issue #218

konkab opened this issue Nov 30, 2020 · 7 comments · Fixed by #554
Labels
bug Something isn't working fix confirmation pending issue has been fixed and confirmation from issue reporter is pending

Comments

@konkab
Copy link

konkab commented Nov 30, 2020

I have two ViewSets subclassed from another ViewSet. Subclasses are decorated with @extend_view_schema with identical method names, but different extend_schema values (different tag names).

The subclasses are located in different apps.

appointments/views.py:

class AppointmentViewSet(viewsets.GenericViewSet):

doctors/views.py:

...
@extend_schema_view(
    notes=extend_schema(tags=["Doctor Appointments"], summary="Get appointment notes"),
    ...
)
class AppointmentViewSet(AppointmentViewSet): # superclass imported from appointments/views.py
...

patients/views.py:

...
@extend_schema_view(
    notes=extend_schema(tags=["Patient Appointments"], summary="Get appointment notes"),
    ...
)
class AppointmentViewSet(AppointmentViewSet): # superclass imported from appointments/views.py
...

One ViewSet is registered in doctors.urls, the other in patient.urls.

"app".urls:

urlpatterns = [
    path('api/doctors/', include('doctors.urls')),
    path('api/patients/', include('patients.urls')),
]

The issue is that "doctors" tags get overriden by "patients" tags. Basically all parameters get overriden by last added path.

It seems like the extend_schema decorators stick to superclass only.

@tfranzel tfranzel added the bug Something isn't working label Nov 30, 2020
@tfranzel
Copy link
Owner

hi @konkab, yes this is a bug in the extend_schema_view mechanics, which are more complicated than they look.

the tests only covered the base class case like:

@extend_schema_view(list=..., ...)
class XViewset(mixins.ListModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet)::
    ....

i'll have to investigate how to fix this.

@elvirTatarevic
Copy link

@tfranzel Any updates on this issue? I am also trying to extend a parent class and a child class, but only the parent extension is applied to both.

@tfranzel
Copy link
Owner

hi @elvirTatarevic! i have not gotten around investigating this further. its a tricky issue. i'll have to deal with 3-4 other issues first. after that i will have a look at it again.

@elvirTatarevic
Copy link

@tfranzel No problem man. We all appreciate everything that is being done. For now, a base class kind of seems to do the trick.

@filipemir
Copy link

Just adding my vote for a fix here. Ran into this today and thought I was losing what little sanity I can claim

ngnpope added a commit to ngnpope/drf-spectacular that referenced this issue Oct 7, 2021
When creating a copy of a method from a parent class we now:

- Ensure that `__qualname__` is defined correctly
  - i.e. `Child.method` instead of `Parent.method`.
  - This isn't essential but helps diagnosing issues when debugging.
- Move application of the decorator to the last moment.
- Deep copy the existing schema extensions before applying decorator.

This fixes tfranzel#218 where two child classes with @extend_schema_view affect
each other - schema extensions are applied to the parent such that the
second child overwrites the changes applied to the first child.

This also fixes my case where a child with @extend_schema_view clobbered
the schema extensions of the parent which also used @extend_schema_view.
ngnpope added a commit to ngnpope/drf-spectacular that referenced this issue Oct 11, 2021
When creating a copy of a method from a parent class we now:

- Ensure that `__qualname__` is defined correctly
  - i.e. `Child.method` instead of `Parent.method`.
  - This isn't essential but helps diagnosing issues when debugging.
- Move application of the decorator to the last moment.
- Deep copy the existing schema extensions before applying decorator.

This fixes tfranzel#218 where two child classes with @extend_schema_view affect
each other - schema extensions are applied to the parent such that the
second child overwrites the changes applied to the first child.

This also fixes my case where a child with @extend_schema_view clobbered
the schema extensions of the parent which also used @extend_schema_view.
@tfranzel
Copy link
Owner

tfranzel commented Oct 12, 2021

@filipemir please reclaim your valuable sanity by checking out the current master branch.

@elvirTatarevic @konkab, would be great if you do that too.

This bug was actually a rather small oversight, but I was unable to see the forest for the trees there. Many thanks to @ngnpope. In #554, we addressed at least 3 different issues regarding isolation/inheritance. I'm not aware of any remaining issues in that regard, which is why I ask you kindly to test those fixes.

let me know if anything is still not behaving as expected!

@tfranzel tfranzel added the fix confirmation pending issue has been fixed and confirmation from issue reporter is pending label Oct 13, 2021
@filipemir
Copy link

Hey @tfranzel. Works for me! With the latest version I was able to erase a bunch of duplicated annotations all over our code which was just the sort of satisfying work I needed at this stage in the day. Thank you!

wmfgerrit pushed a commit to wikimedia/wikimedia-toolhub that referenced this issue Nov 17, 2021
Upgrade drf-spectacular to v0.21.0 to make the fix for
<tfranzel/drf-spectacular#218> available to
our code.

Change-Id: If0b94e35e9a04964983f1f819eab8644c582ddda
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fix confirmation pending issue has been fixed and confirmation from issue reporter is pending
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants