Uploaded image for project: 'Couchbase Documentation'
  1. Couchbase Documentation
  2. DOC-2388

Documentation to cover XATTRs in server reference

    XMLWordPrintable

Details

    • New Feature
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • None
    • spock
    • memcached
    • None
    • DOC-S1, DOC-S2-Nov03, DOC-S3-Nov17

    Description

      Starting in 5.0, XATTRs is a public feature of the system. While SDKs will cover the API and usage and how errors are returned, the details on those errors and the limitations of XATTRs itself needs to be centralized.

      This issue would be done when Couchbase Server documentation has a section that covers:

      • Error codes including the hex value, text returned, and a description of the error condition
      • A description of limitations in the implementation (e.g., XATTR mutations must come before non-XATTR mutations always), as this is not generally enforced in the API
      • A description of what the interface stability is for these features if there are any that are not committed interface

      This may be tracked somewhere already by Chin Hong's team (maybe Tyler Mitchell?).

      On that last bullet item, there are some things like retrieving XATTRs from deleted documents which are considered "Internal". See (https://developer.couchbase.com/documentation/server/current/sdk/java/compatibility-versions-features.html#topic_bhl_2cv_xv__d298e17) for a definition of interface stability. I don't think anything Internal should be covered in these docs, but anything Volatile or Uncommitted should, if there is such a thing.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            Tony Hillman assigning this to you as this relates to Mobile Convergence, which is your area to document for GA.

            matt.carabine Matt Carabine added a comment - Tony Hillman assigning this to you as this relates to Mobile Convergence, which is your area to document for GA.

            Richard Smedley - assigning to you as discussed with Amarantha.  Matt Carabine can help give you some direction, and Tony has also already done several docs (see linked issues).  Ping me if any questions.

            tyler.mitchell Tyler Mitchell added a comment - Richard Smedley - assigning to you as discussed with Amarantha.  Matt Carabine can help give you some direction, and Tony has also already done several docs (see linked issues).  Ping me if any questions.

            Hi,

            Taking the three bullet points one-by-one:

            • Error codes including the hex value, text returned, and a description of the error condition

            We don't currently provide this information in other areas of the documentation; perhaps this could be open for review generally, but not as a specific blocker for the XATTR docs?

            • A description of limitations in the implementation (e.g., XATTR mutations must come before non-XATTR mutations always), as this is not generally enforced in the API

            This question of order specifically is something that should perhaps be done within the APIs. Which ones do this - a question for Brett Lawson (suggested Tyler)?

            Also, re Limitations, in existing documentation:

            https://developer.couchbase.com/documentation/server/5.0/developer-guide/extended-attributes-fundamentals.html

            has:

            "Implications for Sizing

            "Within Couchbase Server, the maximum size for each individual document is 20 megabytes (see Cluster Operations). Extended attributes count against this size-limit: consequently, the size of a document may reflect the presence of data inaccessible to some applications."

            • A description of what the interface stability is for these features if there are any that are not committed interface

            affect all interface features are stable once included, and would only slowly get changed/deleted over the standard deprecation process. Perhaps Trond Norbye could comment if this is/isn't the case?

             

            Given the work already done by Tony Hillman on all of the individual SDKs and XATTR, DOC-2472, can we close this issue in time for official Spock release?

             

            richard.smedley Richard Smedley added a comment - Hi, Taking the three bullet points one-by-one: Error codes including the hex value, text returned, and a description of the error condition We don't currently provide this information in other areas of the documentation; perhaps this could be open for review generally, but not as a specific blocker for the XATTR docs? A description of limitations in the implementation (e.g., XATTR mutations must come before non-XATTR mutations always), as this is not generally enforced in the API This question of order specifically is something that should perhaps be done within the APIs. Which ones do this - a question for Brett Lawson  (suggested Tyler)? Also, re Limitations, in existing documentation: https://developer.couchbase.com/documentation/server/5.0/developer-guide/extended-attributes-fundamentals.html has: "Implications for Sizing "Within Couchbase Server, the maximum size for each individual document is 20 megabytes (see Cluster Operations). Extended attributes count against this size-limit: consequently, the size of a document may reflect the presence of data inaccessible to some applications." A description of what the interface stability is for these features if there are any that are not committed interface affect all interface features are stable once included, and would only slowly get changed/deleted over the standard deprecation process. Perhaps Trond Norbye could comment if this is/isn't the case?   Given the work already done by Tony Hillman on all of the individual SDKs and XATTR, DOC-2472 , can we close this issue in time for official Spock release?  

            The three points raised have been dealt with - the first by raising a new ticket about error documentation, DOC-2802, as there is some debate to be had generally about how and to what extent we document error codes.

            richard.smedley Richard Smedley added a comment - The three points raised have been dealt with - the first by raising a new ticket about error documentation, DOC-2802 , as there is some debate to be had generally about how and to what extent we document error codes.

            People

              richard.smedley Richard Smedley
              ingenthr Matt Ingenthron
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty