Opened 17 years ago
Closed 16 years ago
#7152 closed (wontfix)
Insufficient validation of db_column and db_table when declaring models
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Validators | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Design decision needed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
db_column and db_table can contain special characters like %s which will pass model validation but cause exceptions later. See attached example
Attachments (2)
Change History (7)
by , 17 years ago
comment:1 by , 17 years ago
Component: | Uncategorized → Validators |
---|
follow-up: 4 comment:2 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Well, yes, but does anyone really want to name their tables with characters like % or $?
comment:3 by , 16 years ago
- The db_table string can either be probably escaped or quoted, or 2. the respective model fails validation.
I understand that special characters are unlikely to appear in table names, so 1. is probably not a desirable solution.
But regarding that a program should rather fail during compile time(model validation) than runtime, a simple line of code during model validation checking table_name for special characters might be good.
comment:4 by , 16 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Triage Stage: | Unreviewed → Design decision needed |
Replying to Simon Greenhill:
Well, yes, but does anyone really want to name their tables with characters like % or $?
I think it doesn't really matter if anyone wants that functionallity, the issue is that if someone expects it that fill fail miserably. Or Models reject this, or whe escape db_table ;)
comment:5 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
"Doctor it hurts when I do this"
"Don't do that, then"
We cannot predict what characters will and will not be permitted by every possible storage engine (and we support external databases, so we cannot survey all the possibilities). If the user is going to specify their own database table and column names, it's for a very specific reason and it's reasonable to expect that they understand what is acceptable to their database engine of choice.
model causing exception