incorrect ProgrammingError in IPython

[Kenneth Arnold]

I ran into this today and couldn't debug it. There's something weird in the interaction between IPython (Ubuntu's version 0.8.1-2) and Django.

The symptom is <class 'psycopg2.ProgrammingError'>: current transaction is aborted, commands ignored until end of transaction block after executing a statement that throws a single SQL error. The immediate cause of that, as looking in django.db.connection.queries confirms, is that the query is actually getting run twice. It only happens when not storing the output in a variable; when the statement is an assignment, the real (original) database error is displayed.

Example:

In [1]: from csamoa.conceptnet.models import *
In [4]: from django.db import connection
In [5]: connection.queries
In [6]: a=Assertion.objects.all()[0]
In [7]: connection.queries
Out[7]: 
[{'sql': 'SELECT "predicates"."id", "predicates"."batch_id", "predicates"."raw_id", "predicates"."frame_id", "predicates"."predtype_id", "predicates"."stem1_id", "predicates"."stem2_id", "predicates"."polarity", "predicates"."modality", "predicates"."score", "predicates"."created_on", "predicates"."text1", "predicates"."text2", "predicates"."creator_id", "predicates"."sentence_id", "predicates"."language_id", "predicates"."visible", "predicates"."source" FROM "predicates" ORDER BY "predicates"."score" DESC LIMIT 1',
  'time': '0.005'}]
In [9]: a.creator
... traceback ... execute in db.backends.util...
<class 'psycopg2.ProgrammingError'>: current transaction is aborted, commands ignored until end of transaction block
In [10]: connection.queries
Out[10]: 
[{'sql': 'SELECT "predicates"."id", "predicates"."batch_id", "predicates"."raw_id", "predicates"."frame_id", "predicates"."predtype_id", "predicates"."stem1_id", "predicates"."stem2_id", "predicates"."polarity", "predicates"."modality", "predicates"."score", "predicates"."created_on", "predicates"."text1", "predicates"."text2", "predicates"."creator_id", "predicates"."sentence_id", "predicates"."language_id", "predicates"."visible", "predicates"."source" FROM "predicates" ORDER BY "predicates"."score" DESC LIMIT 1',
  'time': '0.005'},
 {'sql': 'SELECT "auth_user"."id", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."is_superuser", "auth_user"."last_login", "auth_user"."date_joined" FROM "auth_user" WHERE "auth_user"."id" = 21900 ',
  'time': '0.001'},
 {'sql': 'SELECT "auth_user"."id", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."is_superuser", "auth_user"."last_login", "auth_user"."date_joined" FROM "auth_user" WHERE "auth_user"."id" = 21900 ',
  'time': '0.001'}]

but with a minor change to just the last line, we get the correct behavior:

In [5]: b=a.creator
... good traceback ... 
<class 'psycopg2.ProgrammingError'>: relation "auth_user" does not exist

In [6]: connection.queries
Out[6]: 
[{'sql': 'SELECT "predicates"."id", "predicates"."batch_id", "predicates"."raw_id", "predicates"."frame_id", "predicates"."predtype_id", "predicates"."stem1_id", "predicates"."stem2_id", "predicates"."polarity", "predicates"."modality", "predicates"."score", "predicates"."created_on", "predicates"."text1", "predicates"."text2", "predicates"."creator_id", "predicates"."sentence_id", "predicates"."language_id", "predicates"."visible", "predicates"."source" FROM "predicates" ORDER BY "predicates"."score" DESC LIMIT 1',
  'time': '0.005'},
 {'sql': 'SELECT "auth_user"."id", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."is_superuser", "auth_user"."last_login", "auth_user"."date_joined" FROM "auth_user" WHERE "auth_user"."id" = 21900 ',
  'time': '0.002'}]

This smells like an IPython bug, but I'm reporting it here because this would certainly explain all the times when I got those annoying ProgrammingErrors for irrelevant things. Anyone else see this? Or any better clues about what to report to the ipython people?

[Michael Radziej]

postgresql behaves like this: If it finds any error during a transaction, it won't allow you any other statements before you end the transaction, so just roll back. It shouldn't matter at all whether you use ipython or python.

[mmoedt]

I'm running into this error as well, and I can't seem to find an obvious way to trace back to the source of the Programming Error.

Shouldn't django handle the case where the error occurs?

1. give a django error (HTTP 500, like you'd expect)
   • with the bad statement that causes the transaction to abort
2. do the rollback for you

I don't understand how this is an invalid issue. (I'm not saying it's not, but please educate me)

[Malcolm Tredinnick]

It isn't necessarily correct to automatically rollback the transaction and just continue on as if nothing has happened.

Please ask support questions on the django-users list. The resolution for this bug is correct.

[(none)]

Milestone post-1.0 deleted