#23780: Easy to use natural keys from a tuple on meta
-------------------------------------+-------------------------------------
Reporter: scrummyin | Owner: nobody
Type: New feature | Status: new
Component: Core | Version: master
(Serialization) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by freakboy3742):
Personally, I disagree with the original premise - I don't see defining a
pair of natural key functions as "cumbersome". It's two methods, each of
which are relatively straightforward to define for the simple case, but
which can have some interesting edge cases for the complex case - e.g., if
a foreign key is involved in a natural key, do you render the PK value? Or
do you use the natural key of the foreign key? What if that natural key
has a foreign key? What's the precedence of manually defined natural key
function over the Meta defined one? What about if you only define *one* of
the two natural key functions?
I'll note that the provided patch doesn't appear to test any of these edge
cases - it only explores the simple (and obvious) case of "a single value-
based field as natural key".
I see this as a case where explicit is better than implicit. If we
implement this, we're going to have an implementation that is non-trivial
to cover all possible use cases, which means introducing a complexity in
implementation, which will need to be maintained (and will inevitably get
more complex when things like composite fields, and the foreign key
refactor that Anssi is sitting on hit trunk). There's also some
documentation for a new feature, - instead of an explicit API entry point
that implements a specific behavior, you have a configuration value, and
newcomers need to know about and understand the internal behavior before
they can use the feature reliably.
Or, we have a relatively simple 4 lines of explicit code on any project
that needs a natural key; maybe 6 lines of code if it's a complex case
(and it's the complex case that has the complex code - the simple case
doesn't pay any overhead).
So - I'm a -0 on the general idea.
That said, the idea has come up a couple of times in the recent past, so
there's clearly some community interest. If we *must* have an
implementation of this feature, a meta attribute is about as good as it's
going to get - it's certainly better than the "automagically interpret
natural keys from model definition" that has been proposed by others.
--
Ticket URL: <https://code.djangoproject.com/ticket/23780#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.dc978fd09ef305ae59ef823ecb7c8e9f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
