Previously it was only mapping the `type` and `format`, even though
for some field types (like a `MultipleChoiceField`) we map more
than just these. And for some fields (like a `ChoiceField`) we do
not map the `type` at all.
Refs #6846
This provides a way for pagination classes to add pagination properties (`count`, `next`, `results` etc.) to OpenAPI response schemas.
A new method `get_paginated_response_schema()` has been added to `BasePagination`. This method is intended to mirror `get_paginated_response()` (which takes a `list` and wraps it in a `dict`).
Hence, `get_paginated_response_schema()` takes an unpaginated response schema (of type `array`) and wraps that with a schema object of type `object` containing the relevant properties that the pagination class adds to responses.
The default implementation of `BasePagination.get_paginated_response_schema()` simply passes the schema through unmodified, for backwards compatibility.
This is the first part of #6846.
Previously, the response schema for list views was an object representing a single item. However, list views return a list of items, and hence it should be an array.
Further work will need to be done to support how pagination classes modify list responses.
There should be no change for views not determined to be list views.
On Python 3, the ugettext functions are a simple aliases of their non-u
counterparts (the 'u' represents Python 2 unicode type). Starting with
Django 3.0, the u versions will be deprecated.
https://docs.djangoproject.com/en/dev/releases/3.0/#id2
> django.utils.translation.ugettext(), ugettext_lazy(), ugettext_noop(),
> ungettext(), and ungettext_lazy() are deprecated in favor of the
> functions that they’re aliases for:
> django.utils.translation.gettext(), gettext_lazy(), gettext_noop(),
> ngettext(), and ngettext_lazy().
Thanks to Jon Dufresne (@jdufresne) for review.
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
Co-authored-by: Rizwan Mansuri <Rizwan@webbyfox.com>
* Introspect ManyRelatedField data type recursively
For all `ManyRelatedField` objects, we were assuming that the inner type was always a `String`. While this may be true for the default output, a `ManyRelatedField` is a wrapper for a lot of other classes which includes more than just strings. This should allow us to document lists of things other than strings.
* Added test for schemas for many-to-many fields
This adds a test that makes sure we generate the schema for a many-to-many field such that it actually has the right type. For some reason we did not previously have any tests for schema generation that included them, so hopefully this will prevent any future issues from popping up.
This should serve as a regression test for the `items` field on to-many relationships, which was previously forced to a `String` even though in most cases it is a different inner type within the array.
* Fix typo in generators.py
* Fix typo in inspectors.py
* message line too long
* Change backslash to multiline strings
* Removed trailing whitespace from assertion message