#23647: Auto-generated PK field name is not easily configurable
-------------------------------------+-------------------------------------
Reporter: systemsoverload | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 1.7
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by freakboy3742):
Not only do I believe this is a bad tradeoff - I believe it has the
potential to be fundamentally destructive.
Settings are project global. By having a setting, you're enforcing a
behavior for *all* apps in your project - including apps that you have no
involvement in developing or maintaining. That means you can affect the
behaviour of third-party projects by changing the value of a setting. The
potential for hard-to-track-down unintentional side effects is enormous.
Plus, what happens if you change the value of the setting *after*
initially running syncdb? You've just changed the PK name for every model
in a way that isn't tied to the definition of the model itself.
We're already seeing problems of this nature through `AUTH_USER_MODEL` -
which is a system wide setting for the User model. The difference there is
that the concept of a User is something that a project as a whole needs to
have a policy on - primary key usage is, at best, something that a
specific app needs to have a policy on (and no - that wasn't me making an
argument for an application setting).
To me, this is clear example where explicit is better than implicit. If
this got to a technical board vote, I'd be a strong -1.
--
Ticket URL: <https://code.djangoproject.com/ticket/23647#comment:5>
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/073.736e92453b84b8b23c467a179bbba9f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
