Compact tombstones' parents revs

Mobile Sync Gateway
1

Hello. I try to check an ability to compact tombstones in SG. In documentation it’s said that SG performs compact operation for a document in 5 min by default. Here I have simple example of a document with resolved conflict

Raw document 
 {
    "_id": "doc_9",
    "_rev": "2-888888",
    "_sync": {
        "rev": "2-888888",
        "new_rev": "3-81728daea5eeab303b5e80e60e7e077d",
        "flags": 20,
        "sequence": 361,
        "recent_sequences": [
            358,
            359,
            360,
            361
        ],
        "history": {
            "revs": [
                "3-81728daea5eeab303b5e80e60e7e077d",
                "2-a4f7c72e8a7a2451d2fdfa9c1ae8f369",
                "2-888888",
                "1-c14c806c9bc627f753fb32c707b86448"
            ],
            "parents": [
                1,
                3,
                3,
                -1
            ],
            "deleted": [
                0
            ],
            "bodymap": {
                "0": "{\"_deleted\":true,\"b\":1}"
            },
            "channels": [
                [
                    "doc"
                ],
                [
                    "doc"
                ],
                [
                    "doc"
                ],
                [
                    "doc"
                ]
            ]
        },
        "channels": {
            "doc": null
        },
        "time_saved": "2018-03-27T18:17:45.389488646+05:00"
    },
    "b": 999
}

We can see here are no conflicts. But the problem is “bodymap” still contains body of tombstone despite 5 mins expired. OK, I thought it might be problem with auto compact mechanism so I tried to execute compact manually using SG Admin API but it did not help.

Considering Compaction section of this manual https://blog.couchbase.com/database-sizes-and-conflict-resolution/ I expect SG should forget about tombstone’s bodies (actually bodies of their parents) after compaction. Did I get it wrong?

2

It might be happening because you still have unresolved conflicting revisions, and so it’s not auto-deleting/compacting the tombstone revision. It’s a bit hard to tell by looking at the raw Couchbase document, can you use the SG _revtree endpoint and paste the Graphviz output?

https://developer.couchbase.com/documentation/mobile/current/references/sync-gateway/admin-rest-api/index.html?v=1.5#/document/get__db___revtree__doc_

4

image

5

Could you please say should SG store a tombstone’s body in this particular case after _compact call?

6

I realized what happened. While experimenting I saved tombstone revision with key-values (in my example it is key “a”). This is why I still see data in bodymap. I understand this is not regular situation when I want to delete document so I think problem doesn’t exist.

But I have another question - how can I find out that compaction has really worked? There is a way to get revs with bodies through SG API?

7

In the doc you posted, revision 2-8888888 is the winning revision, and so the body for that revision will be kept around (not-compacted)

Could you please say should SG store a tombstone’s body in this particular case after _compact call?

Tombstone revisions don’t typically have bodies (their body is typically just {“_deleted”: true}). Are you saying that you see the body associated with revision 2-a4f not being compacted, and you are expecting it to be?

8

Are you saying that you see the body associated with revision 2-a4f not being compacted, and you are expecting it to be?

I do not know the way to see it. And if I knew I would not be expecting the body in there.

9

If it’s true

Tombstone revisions don’t typically have bodies (their body is typically just {“_deleted”: true})

why I see this (attention to “json” field):

image
image961×933 119 KB

?
What I’m doing wrong?

UPD: this deletions were pulled from SG. This means awful network traffic problems for my app

10

Did you happen to set the K-V properties when deleting the document (i.e. can you double check if the JSON body in your delete request is empty) . Because I would expect that since delete/ tombstoning is effectively adding a new revision, if you are providing a JSON body , its likely that it’s included the deleted revision