Changes between Version 2 and Version 3 of Ticket #24040


Ignore:
Timestamp:
Dec 22, 2014, 9:43:53 AM (10 years ago)
Author:
JorisBenschop
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #24040 – Description

    v2 v3  
    33EDIT: https://docs.djangoproject.com/en/dev/ref/databases/#naming-issues.
    44
    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 line
     5I 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.
    66
    7 
     7'''original report:'''
    88If 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:
    99
Back to Top