id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
24040	_meta.db_table malformed in SQL statement when >31char	JorisBenschop	nobody	"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=('*',)
}}}

"	Uncategorized	closed	Database layer (models, ORM)	dev	Normal	invalid			Unreviewed	0	0	0	0	0	0