Error 400 - Invalid database/document/revision ID

[Brendan Duddridge]

Hi,

I'm getting this error when trying to save any CBLModel to the database. This is on macOS 10.12.6.

Error Domain=CBLHTTP Code=400 "Invalid database/document/revision ID" UserInfo={NSLocalizedFailureReason=Invalid database/document/revision ID, NSLocalizedDescription=Invalid database/document/revision ID}

Is there a way to find out what revision ID is causing the problem or any way of correcting this database?

I tried exporting all the data and importing into a new database, but it didn't resolve the problem. Mind you, my export routine retains the revision ID history and passes them back into the putExistingRevisionWithProperties method. So I suspect that's why it's failing still.

Is there a way to determine if a revision ID is invalid so that I can skip it when I'm exporting my data?

I'm using the getRevisionHistory method on CBLDocument to get the revision histories.

Clearly there's something wrong with the data here, but I need to figure out a way to fix it.

Thanks,

Brendan

[Jens Alfke]

That’s quite odd. There shouldn’t be any way for an invalid revID to get into a database. I hope the file isn’t corrupted. There’s no easy way to find out where in the code the error originates because it isn’t thrown as an exception, just returned by some method.

A valid revID consists of a positive decimal integer followed by a hyphen, followed by one or more arbitrary characters. (If using ForestDB storage, the part after the hyphen has to be an even number of hex digits.)

A valid docID is any non-empty Unicode string that doesn’t begin with an underscore.

(This is from memory, but I’m pretty confident of it.)

—Jens

[Brendan Duddridge]

Well, looking at my export of revision history IDs, they all look fine, in that format. They don't all start from 1 though because lots of edits have happened to some of the documents. I'm using SQLite btw.

 Is it possible that if I'm inserting a historical revision ID that there's no actual revision that matches it and that's where it's getting confused?

I'm going to try ignoring the historical revision IDs during import to see if that solves the problem temporarily.

[Brendan Duddridge]

Well that didn't work. You can't ignore the revision IDs because it's needed to recreate the document.

I'm using this code to import the data:

BOOL success = [newDoc putExistingRevisionWithProperties:jsonObject

attachments:attachmentProps

revisionHistory:revIds

fromURL:nil

error:&error];

I tried just passing in the first of the revIds in the array that I found, but I still had the same error trying to save anything after importing into a new database.

I also tried replacing the first part of the first revisionId I found. E.g. replacing "120-blahblahblah" with "1-blahblahblah". But that also didn't work. In fact, by doing that, not all my records imported. Not sure why.

Still trying to find a solution...

Brendan

[Jens Alfke]

On Jul 22, 2017, at 12:28 PM, Brendan Duddridge <bren...@gmail.com> wrote:

Well, looking at my export of revision history IDs, they all look fine, in that format. They don't all start from 1 though because lots of edits have happened to some of the documents. I'm using SQLite btw.

Hm. Another thing is that when you’re adding a doc with a revision history, the generation numbers in the rev IDs have to be strictly consecutive; no skipping or backtracking.

—Jens

[Brendan Duddridge]

Hm. Another thing is that when you’re adding a doc with a revision history, the generation numbers in the rev IDs have to be strictly consecutive; no skipping or backtracking.

Ah interesting. That could be the problem. I'll have to look for that. Thanks.

I worked around the problem by creating a new revision for every document I was importing instead of using the putExistingRevisionWithProperties method.

Brendan