#24040: _meta.db_table malformed in SQL statement when >31char
-------------------------------------+-------------------------------------
Reporter: JorisBenschop | Owner: nobody
Type: Uncategorized | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by JorisBenschop:
Old description:
> 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=('*',)
> }}}
New description:
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 this is unnecessarily confusing. The hash is created to
comply with the oracle 32-char backend, but as we all know, the hash has a
100% guarantee on failure. So why not catch this error in Django instead
of sending bad data over the line, and creating a cryptic output that can
only be understood if the DB output is set to debug. The current solution
makes no sense. I mean, even truncating would be easier as it also yields
a non-existing table, but it saves running the code that creates the hash.
'''original report:'''
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=('*',)
}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24040#comment:3>
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/071.6ed714ef95f925e829aa085ecc87345d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
