the magic 30 days
This causes so much confusion. If we had a time machine, this is he first thing I’d change
Unless you’re setting a very short expiry (like, on the order of seconds where clock drift between the client and server could be an issue) you might as well always pass the expiry as an epoch second.
max value of expiry of int 32
Yes, unsigned int 32, so the max expiry value is 4294967295 which corresponds to 2106-02-07T06:28:15Z.
I also saw some discussion back in 16 that there might be a change in works to pass an object like value and unit type to be able to set larger offsets based on sec’s.
I don’t know about N1QL, but if you’re using SDK 3 with the KV service you can pass a (let’s say
Duration) of whatever length and the SDK will honor your intent.
will there be a change in couchbase 7 which will effect the expiry or will it be like current where a N1QL update will wipe out the expiry value and to preserve i have to get it and update with original value.
With SDK 3 and the KV service, Couchbase 7 will let you specify
preserveExpiry=true for KV ops that would otherwise reset the expiry value. For N1QL, I’m under the impression it will still be necessary to use the technique described in the blog post vsr1 linked to above.