Code

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#7877 closed (invalid)

incorrect ProgrammingError in IPython

Reported by: kcarnold 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?

Attachments (0)

Change History (4)

comment:1 Changed 6 years ago by mir

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

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 5 years ago by mmoedt

  • Cc mmoedt@… added
  • milestone set to post-1.0
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from SVN to 1.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 5 years ago by mtredinnick

  • Resolution set to invalid
  • Status changed from reopened to closed

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 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.