Hi all,

I'm starting this thread in response to the recent closure as wontfix of Ticket
#14019 <https://code.djangoproject.com/ticket/14019>,
"SQLInsertCompiler.as_sql() failure"

The original summary in the ticket from mlavin goes as follows: "I came
across a problem with SQLInsertCompiler.as_sql function while trying to get
a stacktrace printed on insert errors (using
django-db-log<http://github.com/dcramer/django-db-log>).
I found that the as_sql function has an implicit condition that execute_sql
must be called first because execute_sql sets the return_id attribute."

The two proposed fixes either (a) check to make sure return_id exists
before accessing it, or (b) initialize return_id in __init__ so as to avoid
any implicit conditions that it's already set.

While as stated in the ticket this is not a public API, Django does
publicly support writing 3rd party database backends, and implicit
conditions like this make it difficult to develop and debug 3rd party
backends as well as other 3rd party database logging packages when
something goes wrong.  As kmtracey stated in the most recent comment, it
would be a big help to the larger Django community if methods like this did
not completely blow up when used incorrectly, but instead allowed a more
useful traceback to be raised by the actual offending code.

On a more general level, initializing attributes in __init__() is not a bad
practice, and ensuring that calling str() on an object doesn't raise an
exception is generally helpful too.  Given these issues, I wouldn't be
surprised if applying this fix also avoided similar issues during the
future development of Django itself.  Internal or not, "as_sql" is a
relatively common method, so making it at least somewhat resilient would be
helpful both for Django itself and the broader community of 3rd party apps
and backends.

Thanks in advance for considering re-opening this ticket.

Best,
Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to