Opened 13 years ago
Last modified 9 years ago
#17814 new New feature
Add a way to override related_name on models that you can't edit
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | |
Severity: | Normal | Keywords: | |
Cc: | slav0nic0@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Pull Requests: | How to create a pull request | ||
Description ¶
I use external apps with same name models (for example it's forum.post and blog.post) and have conflict with related_name, both have
user = models.ForeignKey(User, related_name="posts")
I writed patch with principle like ABSOLUTE_URL_OVERRIDES
According to the ticket's flags, the next step(s) to move this issue forward are:
- To add tests to the patch, then uncheck the "Needs tests" flag on the ticket.
- To write documentation for the patch, then uncheck "Needs documentation" on the ticket.
- To improve the patch as described in the pull request review comments or on this ticket, then uncheck "Patch needs improvement".
If creating a new pull request, include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.
Change History (5)
by , 13 years ago
Attachment: | concept.patch added |
---|
comment:1 by , 13 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 13 years ago
possible settings are not the best place for this, but this is the most obvious place, if I meet the discrepancy with the code model, I would like to find it in the settings, but not in another application.
comment:3 by , 12 years ago
Cc: | added |
---|
comment:4 by , 9 years ago
Summary: | RELATED_NAME_OVERRIDES → Add a way to override related_name on models that you can't edit |
---|
I really hate the use of a setting for this (despite the precedent of
ABSOLUTE_URL_OVERRIDES
, which I don't like either). I do think it's a problem that Django should provide some answer for, so accepting the ticket on that basis. I can't immediately think of a better solution than the setting, but I hope we can think of one.