INSERT INTO on deleted document still give revision 1

Good morning everybody.
We recently faced this problem.

We have a web application + mobile android application. The web application communicate directly with the CB server using the SDK and the mobile application with CBLite and SG.
Everything pretty straightforward.

We are looking to a FIXED ID document A

  • The document A exists and it’s sync to the mobile device
  • From the Web Application we delete the document A using the SDK running the query “DELETE FROM BUCKET USE KEYS ‘A’”
  • The document has been deleted to the server, and the deletion revision has been sent to the mobile device. The document is deleted everywhere
  • Now the “issue”
    from Web Application we create again the document A, through the SDK, using the “INSERT INTO” (same issue with UPSERT) statement.
  • The document has been re-created, with revision 1, and it’s NOT propagated to CBLite (because it has a revision 2, the deletion inside)

I was expecting, the second time I recreate the document the revision should be 3. We already found another approach to solve our problem, but I would like to know if it’s something obvious that the second time the revision is still 1 or it’s something we might need to discuss about.

Thanks for any feedback and have a good day.

If you are resurrecting a document via the CBS SDK with the exact same body and generation Id of the original document that was deleted is 1, then the revision id of the resurrected document is same as that of the original document. So it will not be pulled by CBL as revision Ids match.

  • Is there a reason you would create a document, then delete it without any updates and then recreate document with exact same body as the one that was deleted ? Does not sound like a practical use case

If you have a reason for the above workflow, then you should handle doc addition/deletion via sync gateway REST API (so metadata is preserved) or ensure that when you create the document, that you have a slightly different body - have a sentinel value like “createdAt”.

Hi Priya,
We built a tool to easily create/delete documents uploading an excel file. Then ID if missing is generated programmatically using some properties of the file.

So we were testing the tool creating documents (uploading the file), and deleting documents.
We never changed the file during the tests, so the values were always the same.

Do you mean just changing slightly the body of the document, the revision of the document becomes “3” and not “1”?.

The constraint to have a fixed ID wasn’t so strong, so we added a small random part to the ID of the document.
The property createdAt is something we do not really need, but I would consider it as a good practice regardless the use case.
Do you agree?

Thanks and have a nice day.

BTW, just to co

It would still be generated with a generation Id of “1” but the revision Id would be different as contents have changed. Since revision Id has changed, CBL will pull that document (Refer to the initial part of this blog for a discussion on revision tree and revision Id)

Yes. I do.