Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-55102

Elixir search index naming is not cross-compatible



    • Untriaged
    • 0
    • Unknown


      The currently planned design for having search-indexes be defined on a per-bucket basis, rather than being a global object (by having the search index name be prepended by "bucket.scope.") leads to problems with supporting cross-compatibility. The way that this cross-compatibility problem presents itself is such that a developer writing an application will need to know ahead of time which environment they are operating in, and additionally would need to make application code changes in order to run the application in a different environment.

      This is different to the solution that is implemented for N1QL where the query context is specified via a separate query_context field, which allows the SDK to present a consistent interface that can be used across all versions.

      Overall, this tickets intent is to coordinate a solution that would enable the SDKs to expose an interface that customers would be able to use consistently between 7.0, Elixir and 8.0. Its also worth noting that it would be acceptable to require a one-time breaking change to an applications use of the SDK, providing that new interface provides this cross-compatiblity.



      After several conversations with the SDK team, here's what's been decided and what the server supports in the latest source of 7.5/8.0:

      • Current GET, PUT over /index/index will NO LONGER prefix bucket.scope to the index name, going back to how things were pre 7.5.
      • New GET, PUT, POST endpoints for scoped index access, user allowed to use these ONLY if the entire cluster is upgraded to 7.5+.
        1. GET  /api/bucket/{bucketName}/scope/{scopeName}/index .. lists all index definitions whose name prefix contains bucketName.scopeName.
        2. GET  /api/bucket/{bucketName}/scope/{scopeName}/index/{indexName} .. gets the index definition of bucketName.scopeName.indexName
        3. PUT  /api/bucket/{bucketName}/scope/{scopeName}/index/{indexName} .. creates/updates index bucketName.scopeName.indexName
        4. POST /api/bucket/{bucketName}/scope/{scopeName}/index/{indexName}/query .. queries index bucketName.scopeName.indexName
        5. DELETE /api/bucket/{bucketName}/scope/{scopeName}/index/{indexName} .. deletes index bucketName.scopeName.indexName
      • Current POST command for query still works: POST /api/index/bucketName.scopeName.indexName/query .. will query the index bucketName.scopeName.indexName
      • Current GET command for index still works: GET /api/index/bucketName.scopeName.indexName.. will obtain the index definition for bucketName.scopeName.indexName
      • Current DELETE command for index still works as well .. DELETE /api/index/bucketName.scopeName.indexName  .. will delete the index bucketName.scopeName.indexName
      • Current PUT command can still be used to only update an existing scoped index definition: PUT /api/index/bucketName.scopeName.indexName
        • Updating the scope of a scoped index (introduced using the new endpoint) will NO LONGER be allowed, users will have to create a new one. They will however be able to change the collection(s) or other type mappings' definition within the same scope.
      • Characters that were previously not allowed in the `indexName` will remain NOT allowed.
      • On the UI CreateIndex and CreateAlias will go to the new endpoints if the cluster is all upgraded to 7.5. UpdateIndex and UpdateAlias will still go to the older endpoints, as will DeleteIndex and DeleteAlias.
      • A scoped index under the hood is simply a global index with it's `bucket.scope` prefixed to it’s chosen name.


        Issue Links

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



              girish.benakappa Girish Benakappa
              brett19 Brett Lawson
              0 Vote for this issue
              10 Start watching this issue