Interesting. Shouldn't the debug view make absolutely sure that no
exceptions/error are raised uncaught ?
Or if there is now way to do something meaningful with the exception,
at least present it in a meaningful way.
I wonder what the devs have to say on this. I'd file an enhancement
ticket, tho
orestis wrote:
> I wonder why does a cursor has to be involved for the debug page to be
> shown... I'll look into it.
Debug page shows repr()'s for many local objects for each level of the
call stack. And repr()'s of models often do some queries to show
readable representation.
--~--~-
I wonder why does a cursor has to be involved for the debug page to be
shown... I'll look into it.
For the record, I managed to track down by trying to save my model from
the interactive shell. It had to do with the postgres sequences not
being adjusted after a manual insertion of objects with pr
orestis wrote:
> ProgrammingError: ERROR: current transaction is aborted, commands
> ignored until end of transaction block
>
> SET TIME ZONE 'Europe/Athens'
> }}}
>
> I have tried issuing the statement SET TIME ZONE 'Europe/Athens' using
> psql and it runs fine. So, it seems that the problem i
I got this ticket rejected from Akismet:
This is not related to #852, as the errors are thrown when running the
application normally, not the shell.
The errors I get are:
{{{
File "/usr/lib/python2.4/site-packages/django/db/models/base.py",
line 166, in save
cursor = connection.cursor()
