Revision ID in CBL2.6 query

Hi!

CBL2.6 exposes revisionID on Document. Is it possible to also get this information returned via the query api?

Regards,
David

It would be pretty easy to add that, but we’ll need to discuss whether it should be added to the API. Could you describe what you’d use it for?

1 Like

Hi Jens,

I’m updating an internal tool that inspects documents in a CBL db from CBL1.x to CBL2.x. The cblite command line utility is great but the internal tool has knowledge of our document formats to make debugging and verification easier.

IIRC the previous version of the tool has revision id to be able to compare what revisions are on the device compared with what’s on the server, and also lets us know how many times the doc has been updated (similar to cblite revs command). The previous version grabs all the revision ids in a single CBL1.x query when it opens a db. I can change this to fetch rev id when viewing individual document details, but it would be handy to select Meta.Revision in the same way we currently get Meta.Id and Meta.Sequence.

Other than for diagnostic tools I can’t think of another reason for exposing this information in the query api.

Regards,
David

Any thoughts, @pasin ?

1 Like

We currently have a scenario with 1.4.x where we attach files to an entity document via a REST call (which is stored independently in S3.) One of the parameters we pass is entity doc’s revision, as the server needs to handle concurrent attachment requests from different clients that may have different revisions of the entity. Having this functionality in 2.6 would be very helpful when we eventually migrate away fro 1.4.

Sorry, for the late reply. I think at least for consistency, we should be able to get to the document properties (id, sequence,…) via the query. One of the reasons that we decided to add the revision ID property to the document is for auditing or inspection so I think there is no reason not to add it to the query via Meta.revisionID. I will create an issue for that.

1 Like

Also, while it is not that likely to change, the revision ID should not be relied upon for anything other than “it is not the same as this other thing.” The information contained in the revision ID is not guaranteed to remain consistent, and is undocumented.

Do you know which version this change will most likely go into?
It is something that would make life a lot easier for us as we are transitioning from CBL1 to CBL2.

What’s your use case for this ? As indicated by Jim, this is only to be used as a way of determining if a given version of a document is different from another.
Created a ticket that you can track.

We are using the revision for read receipts: to say that a user has seen a certain version of a document.