#22064 closed Cleanup/optimization (fixed)
Invalid related_name passes silently
Reported by: | Konrad Świat | Owned by: | André Ericson |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
Invalid related_name e.g. 'user sets' passes silently. It leads to unpredictable problems. It is not a bug, nor new feature, just RelatedField.check() little iprovement.
Change History (13)
comment:1 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Type: | Uncategorized → Cleanup/optimization |
comment:2 by , 11 years ago
Needs tests: | set |
---|---|
Version: | 1.6 → master |
comment:3 by , 11 years ago
https://github.com/kswiat/django/tree/ticket_22064
work in progress (tests)
follow-up: 5 comment:4 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 11 years ago
Is anyone working on this? Been about 3 months since the last commit on the branch.
comment:6 by , 10 years ago
Has patch: | set |
---|---|
Needs tests: | unset |
Patch needs improvement: | set |
The commit in comment 3 looks like a good start. There's a comment there that says, "There is a problem with regex performance, it must be solved before pull request" so if someone wants to take a look, that would be helpful.
comment:7 by , 10 years ago
Curious if the problem with regex is the fact that the commit uses two regexes or is it that he uses regex at all?
I mean would it be preferable to have a faster less readable regex-free solution or a slower more readable using regex?
Please read this as a general question from someone new here rather than as specific to this ticket.
comment:8 by , 10 years ago
The checks framework is not a runtime code path or a fast path at all, so readability definitely trumps performance here. Barring catastrophic performance issues, which a complex regex can be susceptible to.
Looking at the draft patch commit, a few comments:
- I don't see why the "ends with +" case needs any regex at all. Any related-name ending with "+" is valid, since it won't be used as a Python identifier anyway. (I'm not sure why we even support "ends with +" rather than just "+" -- what's the purpose of including anything before the "+"?). So a simple
.endswith('+')
check should be sufficient there.
- I'd suggest that we also check the
related_name
againstkeyword.iskeyword()
, since using a Python keyword as a related name could also cause trouble.
comment:10 by , 10 years ago
Owner: | changed from | to
---|---|
Patch needs improvement: | unset |
comment:11 by , 10 years ago
Assigned it to myself as it seems to be inactive for months.
Submitted a new patch.
pull request at: https://github.com/django/django/pull/3308
comment:12 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Good idea, that sounds like a perfect use-case for the checks framework.