Conflict when saving, but no conflicts found

16 views
Skip to first unread message

Brendan Duddridge

unread,
Jun 23, 2017, 2:18:16 PM6/23/17
to Couchbase Mobile
Hi,

I'm getting the following error trying to save my CBLModels:

Error saving field: Error Domain=CBLHTTP Code=409 "conflict" UserInfo={NSLocalizedFailureReason=conflict, NSLocalizedDescription=conflict}

2017-06-23 12:13:57.298774-0600 Tap Forms Mac 5[60432:8772572] Conflicted documents: 0



So I wrote some code to detect this and to run through my conflict merging code:

CBLQuery* query = [self.couchDatabase createAllDocumentsQuery];

query.allDocsMode = kCBLOnlyConflicts;


The problem is, when I execute this query, 0 conflicts are found.

How can there be a conflict when saving, but there are no conflicts in the database.

The end result is that my changes I'm making to my CBLModel object are not being saved to the database.

Thanks,

Brendan

Brendan Duddridge

unread,
Jun 23, 2017, 2:34:51 PM6/23/17
to Couchbase Mobile
It seems to do this when using [CBLModel saveModels: modelsToSave error: outError];

When I save an individual model I don't get a conflict. But there are a few other models that need saving at the same time, so that's why I'm using the above. There must be something wrong with one of the models in my unsavedModels list.


Jens Alfke

unread,
Jun 23, 2017, 3:12:16 PM6/23/17
to mobile-c...@googlegroups.com

On Jun 23, 2017, at 11:18 AM, Brendan Duddridge <bren...@gmail.com> wrote:

How can there be a conflict when saving, but there are no conflicts in the database.

What this error says is that saving the document would create a conflict, so the save was aborted. Thus there is no conflict when you look at the db afterwards.

It sounds like the same document was updated on a different thread in between your creating the model and saving it. Actually the update probably happened at almost exactly the same time as your save, because ordinarily CBLModel will detect the update and incorporate it (“rebasing” in Git terms.) But if the two happen at almost the same time there can be a race condition where the save call happens before the notification gets to the model object.

If you retry the save a moment later, like on the next runloop iteration, it should be fine.

—Jens

Brendan Duddridge

unread,
Jun 23, 2017, 4:32:23 PM6/23/17
to Couchbase Mobile
Thanks Jens.

So I tried that and it didn't seem to work:

Here's my output:

14:29:39.155| Database: {{ Begin transaction (level 1)...

14:29:39.156| Database: PUT _id=fld-f3c90dfa980a435ab72046e1deff8939, _rev=2-387048e2ded3cc92db4332743b9e1221 (allowConflict=0)

14:29:39.156| Database: }} Abort transaction (level 1)

2017-06-23 14:29:39.156099-0600 Tap Forms Mac 5[63365:8908908] Error saving field: Error Domain=CBLHTTP Code=409 "conflict" UserInfo={NSLocalizedFailureReason=conflict, NSLocalizedDescription=conflict}

14:29:39.162| Database: {{ Begin transaction (level 1)...

14:29:39.163| Database: }} Commit transaction (level 1)

2017-06-23 14:29:39.233272-0600 Tap Forms Mac 5[63365:8908908] fetch duration: 0.07708799839019775

2017-06-23 14:29:39.233488-0600 Tap Forms Mac 5[63365:8908908] build models duration: 0.0001810193061828613

14:29:39.720| Database: {{ Begin transaction (level 1)...

14:29:39.720| Database: PUT _id=fld-f3c90dfa980a435ab72046e1deff8939, _rev=2-387048e2ded3cc92db4332743b9e1221 (allowConflict=0)

14:29:39.720| Database: }} Abort transaction (level 1)

2017-06-23 14:29:39.719939-0600 Tap Forms Mac 5[63365:8908908] Error saving models: Error Domain=CBLHTTP Code=409 "conflict" UserInfo={NSLocalizedFailureReason=conflict, NSLocalizedDescription=conflict}



and here's the code I wrote to handle it:

+ (BOOL)saveAllModelsInDatabase:(CBLDatabase *)database error:(NSError**)outError {


        if (![NSThread isMainThread]) {

               TFFLog(@"Saving all models on a thread that's not MAIN");

       }


        __block NSError *error = nil;

       __block BOOL success = [database saveAllModels:&error];


        if (!success) {


                // a conflict occurred.


                if (error.code == 409) {


                        dispatch_async(dispatch_get_main_queue(), ^{


                                success = [database saveAllModels:&error];


                                if (!success) {


                                        TFFLog(@"Error saving models: %@", error);


                                }


                        });


                }


                *outError = error;


        }


        return success;


}



I'm not saving on a separate thread in this instance. It's the main thread always.



Brendan Duddridge

unread,
Jun 23, 2017, 5:28:58 PM6/23/17
to Couchbase Mobile
There seems to be just one CBLModel in my database that's causing this problem. I tried to delete it, but it also gets a conflict error:

15:27:40.365| Database: }} Commit transaction (level 2)

15:27:40.366| Database: DELETE _id=fld-f3c90dfa980a435ab72046e1deff8939, _rev=2-387048e2ded3cc92db4332743b9e1221 (allowConflict=0)

2017-06-23 15:27:40.366285-0600 Tap Forms Mac 5[65574:8990246] error deleting document: Error Domain=CBLHTTP Code=409 "conflict" UserInfo={NSLocalizedFailureReason=conflict, NSLocalizedDescription=conflict}

15:27:40.366| Database: }} Abort transaction (level 1)

Brendan Duddridge

unread,
Jun 24, 2017, 2:37:05 PM6/24/17
to Couchbase Mobile
So I somehow managed to delete that field model object that was causing the conflict whenever I did batch saves.

I renamed it, but I'm sure I got another conflict error trying to save it. Then I renamed a different field model object in my database and it saved properly because I was not saving all the models at that time. Then when I quit and re-launched my app, the original field causing the trouble was now gone. Strange but true. So now when I batch save other things I'm no longer getting the conflict error.

Jens Alfke

unread,
Jun 24, 2017, 3:47:44 PM6/24/17
to mobile-c...@googlegroups.com
What do you mean by “renamed”? Document IDs are immutable.

So is this problem specific to bulk-saving models, not when you save them individually?

—Jens 

On Jun 24, 2017, at 11:37 AM, Brendan Duddridge <bren...@gmail.com> wrote:

So I somehow managed to delete that field model object that was causing the conflict whenever I did batch saves.

I renamed it, but I'm sure I got another conflict error trying to save it. Then I renamed a different field model object in my database and it saved properly because I was not saving all the models at that time. Then when I quit and re-launched my app, the original field causing the trouble was now gone. Strange but true. So now when I batch save other things I'm no longer getting the conflict error.

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/f0e40ce7-0e9d-4441-ab0f-2a51c34a09a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Brendan Duddridge

unread,
Jun 24, 2017, 8:47:12 PM6/24/17
to Couchbase Mobile

What do you mean by “renamed”? Document IDs are immutable.

So is this problem specific to bulk-saving models, not when you save them individually?

 By "renamed", I meant just changed the name property of my model object. Not the Document ID. Sorry for the confusion.

It affected individual saves too, but only when I was trying to save that specific model. Because that model was modified somehow (I'm not sure how), it would prevent other models from being saved when I used the CBLDatabase saveAllModels method.

Jens Alfke

unread,
Jun 26, 2017, 12:02:18 PM6/26/17
to mobile-c...@googlegroups.com
I’m stumped by this issue; if you ever get a database that exhibits the same problem, could you zip it and attach it to a bug report?

—Jens

Brendan Duddridge

unread,
Jun 26, 2017, 3:17:57 PM6/26/17
to Couchbase Mobile
Sure, I'll do that if I encounter this problem with a test database of mine. This was a customer's database, so I wouldn't be able to send it.

Thanks,

Brendan
Reply all
Reply to author
Forward
0 new messages