#14019: SQLInsertCompiler.as_sql() failure
-------------------------------------+-------------------------------------
Reporter: mlavin | Owner: tobias
Type: Bug | Status: closed
Component: Database layer | Version: 1.2
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage: Design
Keywords: | decision needed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by kmtracey):
Really? Sigh. This is a real problem hit by people trying to use Django
and a couple of external packages (mssql backend, django db log). Why the
incredible pushback to initializing an attribute in init so as to ensure
that a utility routine won't fall over dead if this "internal api" is used
"incorrectly"? What's the harm? Maybe it would give a clue as to what the
heck has gone wrong with use of this internal api by whatever package is
in error...the current Django code makes it impossible to figure out who
has gone wrong when, because you get a totally useless exception. Why are
we being so user-unfriendly? Sure, it's an internal API but I'm not
exactly surprised if an externally-maintained DB backend uses it, and
given we don't exactly document this stuff very well I think it would be
far more friendly of us to make the small effort to make this code a bit
more foolproof.
--
Ticket URL: <https://code.djangoproject.com/ticket/14019#comment:14>
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.
For more options, visit https://groups.google.com/groups/opt_out.
