Conflict error updating records

Bug #462245 reported by Manuel de la Peña on 2009-10-27
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Manuel de la Peña
Stuart Langridge

Bug Description


The following code will raise a Conflict exception when executed when there is no reason for it to occur:

from desktopcouch.records.server import CouchDatabase
from desktopcouch.records.record import Record

test_data = {
    '_id': '6b8189fd34e844f89604c101730e3473',
    'name' : 'Manuel',
    'surname': ' de la Pena',

record = Record(test_data)
db = CouchDatabase('test')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/dist-packages/desktopcouch/records/", line 155, in put_record
    self.db[record_id] = record_data
  File "/usr/lib/pymodules/python2.6/couchdb/", line 327, in __setitem__
    resp, data = self.resource.put(id, content=content)
  File "/usr/lib/pymodules/python2.6/couchdb/", line 989, in put
  File "/usr/lib/pymodules/python2.6/couchdb/", line 1031, in _request
    raise ResourceConflict(error)
couchdb.client.ResourceConflict: ('conflict', 'Document update conflict.')

I believe the problem is related with the couchdb library when trying to update a new document in the database. The current version in my system is 0.6. I have attached a patch that solves the problem although I would no recommend to use it since it adds an extra web request to delete the current doc in the database. I have contacted the couchdb guys regarding the problem. The related bug report can be found here:

Although the owner of the bug is not desktopcouch perse, it will be nice to provide a temp solution or at least let developers know.

Manuel de la Peña (mandel) wrote :

The correct bug post should be the following from Oct the first: the above mentioned bug has already merge by the python couchdb guys

Manuel de la Peña (mandel) wrote :

I have changes the issue name to a more descriptive one, this will happen with any update!!!

summary: - Conflict error when adding document with same id
+ Conflict error updating
summary: - Conflict error updating
+ Conflict error updating records
Changed in macaco:
assignee: nobody → Mandel (mandel)
importance: Undecided → High
Changed in desktopcouch:
assignee: nobody → Stuart Langridge (sil)
status: New → Triaged
Changed in macaco:
status: New → Triaged
status: Triaged → Invalid
importance: High → Undecided
Chad Miller (cmiller) wrote :

The problem is that we access and update the same document that you want to write.

put_record(r) # mutates r, sets _rev
delete_record(id) # downloads record with that id, updates and sets _rev to new value in DB.
put_record(r) # tries to push with a record revision that is out of date.

Chad Miller (cmiller) wrote :

To say it another way, the act of marking as deleted will make a new revision. You can not put a record again without getting the new revision id from the database.

Manuel de la Peña (mandel) wrote :

Indeed, but I was expecting the behavior of the delete to be the same as the one found in couchdb-python. That is, because you are putting a new version of the document (with the deleted flag) I was expecting the same behavior of the __setitem__ of couchdb-python where the new revision of the document is added, which would allow to perform the mentioned operations.

Changed in desktopcouch:
importance: Undecided → Medium
Changed in macaco:
status: Invalid → Triaged
importance: Undecided → Low
Omer Akram (om26er) wrote :

gwibber is also infected by this bug. so is it something the app should deal with or it can be fixed in desktopcouch?


The reason for this bug to occur is actually quite simple and I believe
is Desktopcouch fault and has no relation what so ever with CouchDb. Let
me explain my statement:

The delete method in the Desktopcouch library is the following:

def delete_record(self, record_id):
        """Delete record with given id"""
        record = self.with_reconnects(self.db.__getitem__, record_id)
        record.setdefault('application_annotations', {}).setdefault(
            'Ubuntu One',
{}).setdefault('private_application_annotations', {})[
            'deleted'] = True
        self.with_reconnects(self.db.__setitem__, record_id, record)

as you can see in the method the document is actually not deleted from
the database but marked as deleted instead. When you executed the given
test code you are trying to update your document with the same id and an
old rev. This is actually a feature used in the server side. I believe
this behavior is easy to solve in two different ways:

1. Ensure that you do not reuse your ids.
2. Add extra logic to the desktopcouch lib to solve the issue.

The bug has been triaged, but if it gets reopened I'm more than happy to
become the owner and provide a solution :D



"""Delete record with given id"""
record = self.with_reconnects(self.db.__getitem__, record_id)
record.setdefault('application_annotations', {}).setdefault(

'Ubuntu One', {}).setdefault('private_application_annotations', {})[

'deleted'] = True
self.with_reconnects(self.db.__setitem__, record_id, record)

On Wed, 2010-06-30 at 19:05 +0000, Omer Akram wrote:
> gwibber is also infected by this bug. so is it something the app should
> deal with or it can be fixed in desktopcouch?

JACQUELINE (ijdisabest) on 2015-01-30
Changed in desktopcouch:
status: Triaged → Fix Released
Changed in macaco:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.