#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 [email protected].
To post to this group, send email to [email protected].
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.
