I am also facing the same problem. Here is the description of my
problem. The code tries to create a new user and emits an error when
an error happens:
try:
user = auth.models.User.objects.create_user(uname, email, password
= passwd)
except db.IntegrityError:
htmldict['msg'] = 'Username "%s" has already been taken. Try a
different one.' % uname
return render_to_response('register.html', htmldict)
Now this gives the error:
Traceback (most recent call last):
File "/usr/lib64/python2.5/site-packages/django/core/handlers/
base.py", line 86, in get_response
response = callback(request, *callback_args, **callback_kwargs)
File "/usr/lib64/python2.5/site-packages/djangobb/users/views.py",
line 88, in signup
return render_to_response('register.html', htmldict)
File "/usr/lib64/python2.5/site-packages/django/shortcuts/
__init__.py", line 18, in render_to_response
return HttpResponse(loader.render_to_string(*args, **kwargs),
**httpresponse_kwargs)
File "/usr/lib64/python2.5/site-packages/django/template/loader.py",
line 107, in render_to_string
return t.render(context_instance)
File "/usr/lib64/python2.5/site-packages/django/template/
__init__.py", line 176, in render
return self.nodelist.render(context)
File "/usr/lib64/python2.5/site-packages/django/template/
__init__.py", line 768, in render
bits.append(self.render_node(node, context))
File "/usr/lib64/python2.5/site-packages/django/template/
__init__.py", line 781, in render_node
return node.render(context)
File "/usr/lib64/python2.5/site-packages/django/template/
loader_tags.py", line 111, in render
return self.template.render(context)
File "/usr/lib64/python2.5/site-packages/django/template/
__init__.py", line 176, in render
return self.nodelist.render(context)
File "/usr/lib64/python2.5/site-packages/django/template/
__init__.py", line 768, in render
bits.append(self.render_node(node, context))
File "/usr/lib64/python2.5/site-packages/django/template/
__init__.py", line 781, in render_node
return node.render(context)
File "/usr/lib64/python2.5/site-packages/django/template/
defaulttags.py", line 123, in render
len_values = len(values)
File "/usr/lib64/python2.5/site-packages/django/db/models/query.py",
line 154, in __len__
self._result_cache = list(self.iterator())
File "/usr/lib64/python2.5/site-packages/django/db/models/query.py",
line 269, in iterator
for row in self.query.results_iter():
File "/usr/lib64/python2.5/site-packages/django/db/models/sql/
query.py", line 206, in results_iter
for rows in self.execute_sql(MULTI):
File "/usr/lib64/python2.5/site-packages/django/db/models/sql/
query.py", line 1700, in execute_sql
cursor.execute(sql, params)
InternalError: current transaction is aborted, commands ignored until
end of transaction block
I did not know that the template rendering also uses the database
cursor. So I am catching the exception but I why should I care about
the cursor. The django model does not expose cursor by default and
that should be used only when I am writing custom SQL queries.
I think that the cursor should rollback if there is an error and then
throw the exception. Thats a more reasonable behavior than what we
have right now.
-Sushant.
Karen Tracey wrote:
> On Tue, Feb 10, 2009 at 9:58 AM, azer <azerkoc...@gmail.com> wrote:
>
> >
> > Hi,
> > I modified django's db/backends/postgresq_psycopg2/base.py and fixed
> > the problem.I added this lines before "cursor = self.connection.cursor
> > ()":
> >
> > # if transaction is broken, run rollback method
> > if self.connection.get_transaction_status()==3:
> > self.connection.rollback()
> > #
> >
> > I hope it will be useful for you too.Also, I've written a blog post
> > about this;
> >
> > http://berraksular.blogspot.com/2009/02/transaction-problem-of-django-and.html
> >
>
> Some description of the problem you are trying to solve here would have been
> useful. Based on what the code does, I guess you are trying to fix the
> problem that once some sort of database error is encountered, PostgreSQL
> refuses to process any subsequent commands in that transaction and instead
> returns another error along the lines of "current transaction is aborted,
> commands ignored until end of transaction block"?
>
> I don't believe what you have proposed here is a good solution. When the
> original error occurs, an exception is raised. In order for your code to
> get to the point of issuing another SQL command in that transaction, some
> code had to catch that exception and decide to continue on instead of
> abandoning whatever is being attempted. It is the code that catches the
> original exception and decides to proceed on anyway that should be
> responsible for restoring the connection to a state where SQL commands can
> be issued. That is the code that has enough context to know it is safe to
> proceed in the face of whatever error caused the exception, and to know that
> rolling back whatever has been done so far and continuing on is OK.
>
> Burying the rollback in the driver essentially hides an error from the
> calling code. This level of code has no context for knowing that it is safe
> to proceed in this situation, rather the reverse. All this code knows is
> that some database error has occurred, and whatever code caught the
> resulting exception did not restore the connection to a usable state, which
> rather implies the code that caught the exception didn't fully understand
> the exception it caught. That's not a situation that should be silently
> ignored.
>
> Karen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
