API to get all the xattrs for a given document, along with its body

Description

Before , XDCR just fetched the target document metadata for source-side conflict resolution. But with , we need to "log" (store in a bucket), both the source document and the target document, involved in a conflict, along with their metadata.
For milestone-1/phase-1 of the project, this is how we do it:
1. Fetch the target document metadata using subdoc lookup on selected vxattrs and system xattrs. If the logging feature is turned on, get the XTOC vxattr in the same call.
2. Perform conflict resolution using the details fetched in (1).
3. If (2) doesn't detect a conflict, we are done.
4. If (2) detects a conflict: Parse the XTOC result obtained in (1), compose another subdoc lookup with all the xattr keys in XTOC and one compulsory spec for document body. This is done with subdoc lookup with command.CAS set to response.CAS returned by (1).
5. If we get KEY_EEXISTS or KEY_ENOENT, go to (1) and retry everything.
6. Otherwise, log the results and we are done.

As I understand there is a limit on number of lookup paths as 16. One path is always guaranteed to be document body. That leaves us with 15 xattr paths. With this context I have a couple of questions and hence creating this MB for tracking purposes:
1. Is the above described steps the most optimal way to get all the xattrs + document body right now? If yes, does it affect target KV performance by a lot in addition to XDCR performance hit due to XTOC parsing, retries etc.
2. Will there be a scope for new improvement wherein the document body and xattr section will be returned with a single API? Or a new vxattr for subdoc lookup, say $body whose response will be a combination of both document body and xattrs.

Environment

None

Gerrit Reviews

MB-63201: Add GetEx and GetExReplica repo:kv_engine branch:master

Release Notes Description

None

Activity

Show:

Abhijeeth Nuthan January 15, 2025 at 12:24 AM

Yes we still have the code in place. Filed to track the improvement to move to new API.

Sumukh Bhat November 18, 2024 at 11:10 AM

Hi , wanted to double-check the GetEx’s behaviour for handling responses on the client side:

  1. Sounds like for a tombstone, KEY_ENOENT with response.Cas = 0 is returned.

  2. For a locked document, LOCKED response is returned (unlike getMeta where SUCCESS with response.Cas == MaxCas (UINT64_MAX))

Is that correct? Any special responses that the client needs to be aware of?

CB robot October 7, 2024 at 2:13 PM

Build couchbase-server-8.0.0-1882 contains kv_engine commit 092ac42 with commit message:
: Add GetEx and GetExReplica commands

Vinathi Kanna September 25, 2024 at 4:03 AM

Removing Morpheus fix version and adding Ponyo.

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Ashwin Govindarajulu

Reporter

Story Points

Components

Fix versions

Affects versions

Priority

Instabug

Open Instabug

PagerDuty

Sentry

Zendesk Support

Created August 19, 2024 at 2:05 PM
Updated January 15, 2025 at 12:24 AM
Resolved October 9, 2024 at 6:50 PM
Instabug