This is the right behavior. When purging a local document, only the local copy of the document will be removed. You can delete a document instead so that the deletion could be synced to Sync Gateway. However delete a document will not completely delete a local document, it will create a new tombstone revision that can be synced.
@pasin thanks for your reply. What’s the api call to delete a document like you have said?
I need to have the contents of a bucket replicated through several devices. When I delete a document from my local device I want it to disappear from the other devices as well. Does this make sense?
@sinosoidal, you can use this API, .deleteDocument() to delete doc for couchblite 2.0 and up.
Also make sure you replication is continuous or start a new replication in order to replicate deletion on all devices.
So a deleted document is never actually deleted. It will only be marked as deleted through the flag kRevDeleted and will never leave the local or remote database. Is this correct?
So, when I list all the documents, should I filter the output to not include documents that have the kRevDeleted flag? What’s the recommended approach?
What’s the best document of Coouchbase documentation to refer to database design and basic operations overview?
Incorrect. The entire reason things are done this way is so that a deletion can be synced to a remote endpoint (or multiple).
This is done by default unless you specifically request deleted documents. EDIT This is true for Couchbase Lite but I am not 100% sure if Couchbase Lite abstracts this behavior or not so don’t take my word on that.
LiteCore is not an officially supported project on its own, and does not have any documentation other than what is on the wiki of the GitHub repo. Know that you face dragons if you take on this project directly, but that being said it is the core component of Couchbase Lite and is not going to disappear.
Purging is for local only removal of a document. It’s useful if you are wanting to save space on your device but don’t want the documents to be deleted elsewhere. It’s a little fragile in that if you get another update to the document later it will come back, but with proper care it can help save some space on the local device.
The thing you are missing about deletions is basically the entire way that things get saved in the backend. You don’t just write a document and then later write it again with the same ID to change it, because that’s not safe at all for distributed systems. You need to maintain a revision history tree by making your edits on top of the previous one (if two different clients make an edit to the same document then you’ve got a “conflict” just like in Git). I’d suggest looking through the tests in c4DocumentTest.cc to get a better understanding of how it works but at a high level, you need to establish a history back to an existing revision in order to save a deletion (you cannot simply create a new document that is already deleted). That means you need to get the revision ID of the previous existing revision and add it to the request’s history before you attempt to save.
Ah yes I forgot about c4doc_update. That is the preferred method actually. Beware that kRevKeepBody is possibly not entirely reliable so don’t count on it.
Queries ignore deleted docs, unless you explicitly refer to the ._deleted property in the where clause.
You can make a deleted doc disappear eventually by setting an expiration date on it. Or you can purge all deleted docs (we call those “tombstones”) by querying for them and calling Purge on each one.
Bodies of deleted docs are usually empty. There are some cases where you’d want to put data in a deleted doc, to get it assigned to the right channel in Sync Gateway, but it’s not common.