./manage.py index does not work in django 1.4

[GoogleCodeExporter]

My env:

Django          - 1.4          - active 
Djapian         - from svn trunk
xapian 1.2.7
xapian-bindings 1.2.7

I've got very basic case, one model, one indexer with two text fields. After 
updating model objects, ./manage.py index throws:

Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/core/management/__init__.py", line 443, in execute_from_command_line
    utility.execute()
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/core/management/__init__.py", line 382, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
    output = self.handle(*args, **options)
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/djapian/management/commands/index.py", line 201, in handle
    per_page, commit_each)
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/db/transaction.py", line 209, in inner
    return func(*args, **kwargs)
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/db/transaction.py", line 203, in __exit__
    self.exiting(exc_value, self.using)
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/db/transaction.py", line 288, in exiting
    leave_transaction_management(using=using)
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/db/transaction.py", line 52, in leave_transaction_management
    connection.leave_transaction_management()
  File "/Users/cypreess/.virtualenvs/ultragaleria/lib/python2.7/site-packages/django/db/backends/__init__.py", line 119, in leave_transaction_management
    raise TransactionManagementError("Transaction managed block ended with "
django.db.transaction.TransactionManagementError: Transaction managed block 
ended with pending COMMIT/ROLLBACK

I'am not able to tell what exactly causes a problem because 
django.db.transaction.TransactionManagementError covers the exception from 
djapian.


PS. --rebuild works without a problem

Original issue reported on code.google.com by cypre...@gmail.com on 16 Apr 2012 at 6:55

[GoogleCodeExporter]

Have the same proble. Looks like a transaction is just never commited. The 
commiter class doesn't look to do anything, All of its methods are empty.

Original comment by e3satter...@gmail.com on 23 Jun 2012 at 6:20

[GoogleCodeExporter]

I've found a bug in current djapian.utils.commiter.Commiter implementation 
recently. A fix and unit-tests are almost ready.

Original comment by esizi...@gmail.com on 31 Aug 2012 at 1:45

• Changed state: Accepted

[GoogleCodeExporter]

Commited a fix to Commiter.create() in r394 - please check if it helps.

Original comment by esizi...@gmail.com on 31 Aug 2012 at 1:55

[GoogleCodeExporter]

I have the same issue too. 
In djapian code I already have r394 fix, but the problem still here.
When I run index commend I have:
django.db.transaction.TransactionManagementError: Transaction managed block 
ended with pending COMMIT/ROLLBACK
And when index --rebuilds it's ok

Original comment by d.aki...@gmail.com on 14 Oct 2012 at 11:39

[GoogleCodeExporter]

Did you tried to run Djapian's test suite standalone (not as a part of your 
project)? Was it successful?

Did you tried with Djapian's test suite or in your own environment? If the 
latter is the case, which DB did you use when the problem has been reproduced 
after the fix? Could it be somehow related to the problem mentioned here: 
https://docs.djangoproject.com/en/dev/releases/1.5-alpha-1/#behavior-of-autocomm
it-database-option-on-postgresql-changed ?

Original comment by esizi...@gmail.com on 8 Nov 2012 at 6:37