Releases: wq/django-natural-keys
v2.1.1
natural-keys 2.1.0
natural-keys 2.1.0 improves natural key detection and handling, particularly for null relationships. Otherwise, this release is essentially compatible with natural-keys 2.0.0, but note the type change for the output of natural_key()
.
All changes by @sheppard.
- Don't crash when serializing models with null foreign keys (#18, bbe6f64)
- Return a Python
tuple
instead of alist
fromnatural_key()
andget_natural_key_fields()
. The documentation already assumestuple
output, as that is a more correct type for these values. This change should not affect normal usage. (bbe6f64) - Don't automatically build nested natural key serializers for reverse relationships (142ffd0)
- Allow overriding natural key detection via
NaturalKeyModelSerializer.is_natural_key_model()
(86958a7) - Update code style, switch to pyproject.toml, and test with latest Python and Django versions (309fcee, 4e4fa11)
natural-keys 2.0.0
natural-keys 2.0.0 improves support for Django 3.2 and drops support for Python 2.7.
New Features
- Ignore
BigAutoField
in addition toAutoField
when detecting single unique key (#16, #17 via @marcosox) - Detect
UniqueConstraint
in addition tounique_together
, and makeUniqueConstraint
the recommended option (#14) - Support using
natural_keys.models
without installing Django REST Framework (#15) - Move to Github Actions
Breaking Changes
- This release removes support for EOL versions of Python and Django, including Python 2.7 and Django 2.1.
natural-keys 1.6.0
natural-keys 1.6.0 confirms compatibility with Python 3.8, Django 3.0, and Django REST Framework 3.11. Other than a minor fix for DRF 3.11, the functionality remains the same.
natural-keys 1.5.1
natural-keys 1.5.1 adds a defaults
keyword argument to get_or_create_by_natural_key()
and find()
. This is based on the similar argument for get_or_create()
, and is important when you have required fields on a model that are not part of a natural key.
While get_or_create()
accepts keyword arguments, get_or_create_by_natural_key()
and find()
use positional arguments for the natural key fields (like get_by_natural_key()
), with defaults
being the only keyword argument.
instance, is_new = Event.objects.get_or_create_by_natural_key(
'ABC123', date(2016, 1, 1),
defaults={
"name": "Example Event",
"public": True,
}
)
natural-keys 1.5.0
natural-keys 1.5.0 ensures that natural_key_slug
can only be passed as a kwarg to NaturalKeyQuerySet.filter()
. The implementation in 1.4.0 was breaking the common use case of passing in a Q
object as the first argument (#8). This was fixed thanks to contributions from @arvindch (#9), @marcosox (#10), and @github-account-because-they-want-it (#11).
Note: If you were relying on this (unintended) feature, you will need to update any instances of e.g.
MyModel.objects.get("abc-123")
with one of the following:
MyModel.objects.get(natural_key_slug="abc-123")
MyModel.objects.get_by_natural_key("abc", "123")
Other changes in this version:
- Option to specify natural key fields via
_natural_key
instead ofMeta.unique_together[0]
(#9 via @arvindch) - Export
NaturalKeyModelManager
&NaturalKeyQuerySet
in top level module (#9) - Update test matrix to add Python 3.7 and Django 2.1. Django 1.8 LTS is still included for now though it is technically deprecated.
- Integrate setuptools_scm; use markdown for PyPI readme; clarify (non-)uses of
NaturalKeySerializer
,
natural-keys 1.4.0
- Preliminary support for natural key slugs