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.
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?
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
Second, although the TTL in always in seconds on the doc (property “expiration” in its metadata) there can be further confusion as in languages like Node (e.g. JavaScript) the native Date construct is in milliseconds and thus it depends on the Language, API and/or SDK used to determine what you need to pass (seconds, or milliseconds, or some date object).
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.
However starting in 6.6.1 Eventing now supports Advanced Bucket Accessors where you can now directly set the TTL (or expiry) with KV instead of dropping down to a N1QL(…) function as per this example advancedDocControlledSelfExpiry using a basic JavaScript Date object - thus here we are using milliseconds to set the TTL in this instance (and the underlying server code takes care of converting to seconds). This is about 5X faster as it is a pure KV operation.
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)
