Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#7877 closed (invalid)

incorrect ProgrammingError in IPython

Reported by: Kenneth Arnold Owned by: nobody
Component: Database layer (models, ORM) Version: 1.0
Severity: Keywords:
Cc: mmoedt@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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?

Change History (4)

comment:1 Changed 8 years ago by Michael Radziej

Resolution: invalid
Status: newclosed

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.

comment:2 Changed 8 years ago by mmoedt

Cc: mmoedt@… added
milestone: post-1.0
Resolution: invalid
Status: closedreopened
Version: SVN1.0

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)

comment:3 Changed 8 years ago by Malcolm Tredinnick

Resolution: invalid
Status: reopenedclosed

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.

comment:4 Changed 8 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top