Opened 10 years ago
Last modified 10 years ago
#24040 closed Uncategorized
_meta.db_table malformed in SQL statement when >31char — at Version 2
Reported by: | JorisBenschop | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I cant imagine this is not a known issue, but I havent been able to find it. Please show me the duplicate if there is one.
EDIT: https://docs.djangoproject.com/en/dev/ref/databases/#naming-issues.
I still think is is unnecessarily confusing. The hash is created to comply with the oracle 32-char backend, but as wel all know that this hash has a 100% guarantee on failure, why not catch this error ini django instead of sending bad data over the line
If I create a model (django dev, oracle 11.2 backend), the sql statement is distorted if the db_table is over 31 characters. Almost like a buffer overflow:
GOOD:
_meta.db_table='variant_owr\".\"biomaterial_type'
DEBUG (0.003) QUERY = u'SELECT COUNT(:arg0) AS "__COUNT" FROM "VARIANT_OWR"."BIOMATERIAL_TYPE"' - PARAMS = (u'*',); args=('*',)
BAD:
_meta.db_table='variant_ownr\".\"biomaterial_type'
DEBUG (0.002) QUERY = u'SELECT COUNT(:arg0) AS "__COUNT" FROM "VARIANT_OWNR"."BIOMATERIAL92C0"' - PARAMS = (u'*',); args=('*',)
_meta.db_table = 'ababababababxxxabababababababab'
DEBUG (0.004) QUERY = u'SELECT COUNT(:arg0) AS "__COUNT" FROM "ABABABABABABXXXABABABABABACAD7"' - PARAMS = (u'*',); args=('*',)
Change History (2)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|---|
Summary: | _meta.db_name malformed when >30char → _meta.db_table malformed in SQL statement when >31char |
comment:2 by , 10 years ago
Description: | modified (diff) |
---|---|
Severity: | Release blocker → Normal |
no comment. user error