What's the n1ql equivalent of collection.get_and_lock

SQL++
,
1

what’s the n1ql equivalent of collection.get_and_lock

2

@vsr1 what’s the n1ql equivalent of collection.get_and_lock

3

@avsej what’s the n1ql equivalent of collection.get_and_lock?

4

That KV API only. N1QL doesn’t support it

5

Thank you @vsr1

Does the KV API expose a REST API? i’m developing a serverless library that uses the couchbase REST API in edge environments like cloudflare workers where binaries are not supported (not a full nodejs environment).

6

The KV does not support a REST API - because documents reside on different nodes based on the key and the cluster configuration.
The upcoming Data API will provide a REST API for Capella.

7

Thank you @mreiche,

I also realized DATA API doesn’t have a REST,

What is the timeline when it’ll be released?, can you advise on how i’d archive the get_and_lock via other means or i’ll entirely have to wait for when the REST for DATA API is released.

8

I don’t think we are talking about the same Data API. I have no information other than at some point there will be a REST-like API for Capella - including KV.

I’m developing a serverless library that uses the couchbase REST API in edge environments like cloudflare workers where binaries are not supported (not a full nodejs environment).

Ok. Right now, what you need to do to support that is build a service which does have the full SDK and acts as a facade to the Couchbase Cluster.

9

I meant having a REST API for KV, i assumed it’s part of the DATA API, (if you look at the REST docs, DATA API doesn’t exist yet, or i’m looking in the wrong places )

Running a facade would be expensive, part of making the serverless wrapper was to utilize low resource environments,

I think i might make a locking simulation like something similar in unix/linux,

basically my get_and_lock would create an additional document with 30 sec expiry,

  • when mutating the same document i check whether it has the lock document
  • to remove the lock i delete the lock document or just let it expire.
10

You will still have your serverless wrapper. It will still be low resource.

But instead of accessing the cluster directly, it will need to access your facade service. There is currently no way to leverage kv operations on kv nodes without using the SDK. Unless you want to write your own client - memcached/docs/BinaryProtocol.md at master · couchbase/memcached · GitHub

basically my get_and_lock would create an additional document with 30 sec expiry,

  • when mutating the same document i check whether it has the lock document
  • to remove the lock i delete the lock document or just let it expire.

Sure, you could do that. But given that a query operation is about 20 times slower end-to-end than a kv operation, that create-lock-document, perform-read-document, perform-update-document, delete-lock-document is going to be about 40 times slower than a kv-get, kv-replace (or kv lookupIn, kv mutateIn) relying on cas for optimistic locking, or kv-get-and-lock and kv-mutateIn.

btw - you don’t have to separately check if the lock document exists. To enter the “synchronized” code section, just create the lock document - it creation succeeds, you have the lock. If it fails, the document was already locked.

1 Like
11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.