Changes between Version 2 and Version 3 of Ticket #24040
- Timestamp:
- Dec 22, 2014, 9:43:53 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #24040 – Description
v2 v3 3 3 EDIT: https://docs.djangoproject.com/en/dev/ref/databases/#naming-issues. 4 4 5 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 line5 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. 6 6 7 7 '''original report:''' 8 8 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: 9 9