I’m reading up on the use of atomic counters and their use. One thing that I’m is don’t these require an index on the Document ID to make them useful? In the examples I’ve seen, there is no discussion about the index for them. Perhaps the assumption is that there is a primary index in place already.
Anyhow, since the document ID would take on these counters for versioning (or other use…), an example would be like:
MyDocumentType@@SomeUID@@Counter
So that means in order to look up a particular document, I won’t be able to use USE KEYS or any SDK’s get() since I won’t know the exact document ID right? I could only look up the document via N1QL including the predicate WHERE meta().id LIKE "MyDocumentType@@SomeUID%" to that extent thus requiring an index on meta().id?
It seems that the counters are just a scalar value saved in a document based on another forum post:
If that’s the case then getting the actual document ID would be easier as the value can be retrieved.
What if I have many documents that can have many versions? Use a different counter for each document?
Sorry, I’m just trying to wrap my head around the counter and versioning thing.
If you know the FULL document ID, you can do what Prasad suggested earlier.
SELECT doc FROM mydocs doc USE KEYS “doc:12344”;
USE KEYS will give the consistent and most recent value.
If you want to get a RANGE of documents based on the pattern, you use the index to fetch the data.
If you have many versions, you can either include the versioning within your document key definition or inside the document and use appropriate queries.
Remember, the indexes are a bit behind the data nodes since indexes are maintained asynchronously (eventually).
Thanks @keshav_m.
I should have said many versions but only for different “type” (e.g., routes, airline, etc. for the travel-sample), but based on what you said, I would just have to use a different counter definition/name for each “type”.
So by using the document ID (e.g., USE KEYS) will avoid the async lag of the index (e.g., no need to worry about RESULT_PLUS/AT_PLUS if using the document ID)?
Agreed with @keshav_m, though I’d just note that USE KEYS is the functional equivalent of KV, but in a non-abstract sense it’s rather different. There would be two network hops (one could be localhost, in a small deployment) and an additional level of parsing responses along with other processing.
Of course, you may get additional value from that processing if you’re using the results further in the N1QL statement with a join, projections, or applying other functions.
