This patch allows a viewset to define a pattern for its lookup field, which the router will honor. Without this patch, any characters are allowed in the lookup field, and overriding this behavior requires subclassing router and copying and pasting the implementation of get_lookup_regex.
It's possible it would be better to remove this functionality from the routers and simply expose a parameter to get_lookup_regex which allows overriding the lookup_regex. That way the viewset config logic could be in the a subclass, which could invoke the super method directly.
I'm using this now for PostgreSQL UUID fields using https://github.com/dcramer/django-uuidfield . Without this patch, that field passes the lookup string to the database driver, which raises a DataError to complain about the invalid UUID. It's possible the field ought to signal this error in a different way, which could obviate the need to specify a pattern.
This fixes a bug that was introduced in 28ff6fb [1] for the
browsable API, specifically with how it handled default values
for boolean fields. Previously, it had a global default for
boolean fields set to `False`, which was different than the
standard None that was used elsewhere. Because this only needed
to be done for the browsable API, a fix was put into place that
only set the default to `False` when form data was passed into
the serializer. This had the unintended side effect of overriding
any default set on the boolean field.
This fixes#1101 [2] by only overriding the default if the default is
`None`, which is the default for all fields.
[1]: 28ff6fb1ec
[2]: https://github.com/tomchristie/django-rest-framework/issues/1101
Check for __getitem__ and then attempt to convert to a dict.
The check for __getitem__ is there as there's no universal way to
check if an object is a mapping type, but this is a likely proxy
The empty value defaults back to '' (for backwards-compatibility) but
is changed automatically to None for ModelSerializers if the `null`
property is set on the db field.
- use the standard paginator.validate_number method rather
strict_postive_int.
- support optional paginator method, default_page_number, to get the default
page number rather than hard-coding it to 1
- this allows supporting non-integer based pagination which can be an
important performance tweak on extermely large datasets or high request
loads
- relatively thorough unit tests of the changes
