Closed GoogleCodeExporter closed 9 years ago
To explore more precisely this issue I need concrete information about
"sometimes" cases.
Original comment by daevaorn
on 23 Nov 2009 at 10:25
Hi daevaorn,
Thanks for your answer...
I'm sorry, but I could not reconstruct the "sometimes" cases. We have a running
webpages and every day while readers visit our pages we receive this error.
Is there an option to deactivate the autoupdate function? For us it would be
sufficient to update the database once a day...
Thx, Hans
Original comment by braxmeie...@gmail.com
on 26 Nov 2009 at 8:54
Hi daevaorn,
Now we found a solution. The problem arises using postgres together with
djapian. The
problem was a sequence out of sync with its automatically incremented field data
(http://docs.djangoproject.com/en/dev/ref/django-admin/ -> django-admin.py
sqlsequencereset)
Regards, Hans
Original comment by braxmeie...@gmail.com
on 5 Dec 2009 at 9:59
Oh, this is intersting!
How do you think can Djapian do something to prevent such error conditions?
Original comment by daevaorn
on 5 Dec 2009 at 10:19
May be this is an idea?
From http://trac.edgewall.org/ticket/8575
... We add a update_sequence method to the db backend classes, which is much
like the
get_last_id method. The plugins would be responsible for calling it, but at
least
there would be a db independent method for it.
Original comment by braxmeie...@gmail.com
on 8 Dec 2009 at 1:47
Ok. I think this issue is not the Djapian authority.
Original comment by daevaorn
on 13 Dec 2009 at 9:08
Update: The IntegrityError "duplicate key value violates unique constraint
djapian_change_content_type_id_key" is caused, if there are equal search
requests at
the same time. That explains why we "received" the error only sometimes. It
looks like
there's a problem with postgres transactions and the save method in
django/djapian.
Original comment by i...@pagewizz.com
on 17 Feb 2010 at 12:51
This looks like a race condition on
https://code.google.com/p/djapian/source/browse/trunk/src/djapian/models.py#32
: if multiple saves happen on the same model in parallel, it's possible that
another thread will create a conflicting Change record in the window between
the 'get' test returning no results, and the subsequent 'save' on the new
change object.
Wrapping the 'create' method in a @transaction.commit_on_success decorator (as
per the attached patch) seems to fix it for me, but I'm damned if I know how to
write a unit test to reliably replicate this!
Original comment by westdotc...@gmail.com
on 17 Apr 2013 at 10:05
Attachments:
Original issue reported on code.google.com by
braxmeie...@gmail.com
on 23 Nov 2009 at 3:09