On Wednesday 29 August 2007 13:40:44 George Vilches wrote:
> I looked at the possibility of both of those fixes, and they seem
> doable, but they would require adding special handler code just for
> QuerySets (especially the one to get the SQL generated code instead
> of the QuerySet). I think I
This sounds to me like another advantage to having database "modes"
that are being discussed in other threads. Once the debugging view
begins, it could switch the db connection into a non-committal mode,
so the existing QuerySets don't actually touch anything.
-Gul
On 8/29/07, George Vilches <[E
Jeremy Dunck wrote:
> On 8/28/07, George Vilches <[EMAIL PROTECTED]> wrote:
> ...
>> Something seems very wrong about this situation, that debugging could
>> cause another query to execute (especially an unintended query), but I
>> don't know what the correct way to go about fixing or preventing i
On 8/28/07, George Vilches <[EMAIL PROTECTED]> wrote:
...
> Something seems very wrong about this situation, that debugging could
> cause another query to execute (especially an unintended query), but I
> don't know what the correct way to go about fixing or preventing it.
> I've tried a bunch of
Quick summary: If Django errors during a QuerySet evaluation with
DEBUG=True, the built-in 500 handler in views/debug.py causes the last
QuerySet (one filter shorter than the final version) to be executed, as
in the SQL statement hits the database.
This is very bad if there was only a single
