Would it be possible to improve documentation about expiration / ttl?
Documentation is a bit confusing, sometimes Expiry is mentioned, sometimes TTL, sometimes in milliseconds, sometimes in second, whereas Expiration doc mentions only TTL.
createBucket : BucketSettings has maxTTL
createCollection : collectionspec has maxExpiry
getAndTouch : getAndTouch arguments has expiry
touch touch arguments has expiry
get : get arguments has withExpiry
(not sure i got them all)
The sentence in setting Document expiration is also confusing: “By default, Couchbase documents do not expire. However, the expiration value may be set for the upsert, replace, and insert operations when modifying data.”
It could lead to understand expiration delay/date can be set in upsert, replace, insert, which is not the case. Some examples about changing expiry/ttl after upsert with touch could be given, as in Eventing example.
What about mutatein and lookupin ? do they remove expiration settings of a document as well?
Thanks @linqFR for your contribution. @Richard_Smedley can you please take a look at it ?
Reading sdk-rfcs 3, maxTTL is deprecated for createBucket.
Thanks for bringing this up - and for taking out the JIRA issues.
We’ll work on getting the docs updated, and clarifying them where they are not clear on this issue.
Super ! and maybe you could add what just came up with Nodejs SDK3.1.1 : maxExpiry/maxTTL is only available for Entreprise Edition (even for 7.0 beta!!)
First, the use of TTL/expiry can be confusing if it is an absolute unix timestamp it is pretty straightforward in N1QL and most of our SDKs (number of seconds since epoch) is just what you pass it. But you can also pass a fairly small number less than 30 days it is an offset for more details refer to document-expiration. You also need to understand the “precedence” as disclosed in buckets:expiration
Yes I agree that the above can lead to a bit of a painful learning curve until the concepts are fully understood.
Now for some fun stuff (from the pure Eventing perspective - hey I am the Eventing PM this is my focus) look at the recently updated 6.6 documentation (sorry but the 7.0 beta isn’t quite current WRT Eventing - I will be working on this 7.0 beta docs shortly)
In 6.5.1 and 6.6.0 you could set the TTL (or expiry) in Eventing like this example docControlledSelfExpiry here we drop to N1QL via the N1QL(…) function and update the expiration via a USE KEYS clause. And here we use seconds when we set the TTL.
Thanks for explanation !
I had no trouble to understand it all and the only pain in learning curve is inconsistency in documentation and discovering that docs are not consistent from one page to another and from code.
Specs for SDK 3.0 made it clear : maxExpiry instead of TTL !
Fine to me, as it can be a date or a delay, whereas TTL has more meaning for just a delay.
But anyway again, concept and explanation in docs are clear, but a bit spread in different pages and above all not consistent within SDK docs and code.
Same for units: often introduced as millisecond in docs, whereas clearly in code, seconds are expected, unless one wishes 1000 times longer delay. Besides, seconds sound logic to me… I cannot imagine how one can guess how many
processing milliseconds a process would require, which could lead to unstable programmes.
I would be interested by Eventing… but unfortunately not in 7.0 Community Server version (even in beta)