Cannot set expiry via java client

Hi there,

I’m using java-client 2.7.14 to connect CB server CE 6.0.0. To create a document with expiry, I’m using JsonDocument.create(String id, int expiry, JsonObject content) with expiry = 86400 for 1 day (afaik, for expiry < 30 days we set seconds, otherwise epoch as expiry value) . I can debug and track this value set correctly document) ->
document=JsonDocument{id = ‘test-id’, cas=0, expiry=86400, content={ … }}

After bucket.insert(…) i don’t do any mutation operation more, yet when I query for the document I just inserted, I always see it’s “expiration” is zero:

SELECT META().* FROM test-bucket WHERE META().id = ‘test-id’

“cas”: 1587917914460127232,
“expiration”: 0,
“flags”: 33554432,
“id”: “test-id”,
“type”: “json”

what am I missing here, do you have any ideas?

Your expiration will be honored. The support of extracting current TTL via APIs just doesn’t work.

Try a short value (10s) and you’ll see your document go poof!

1 Like

@unhuman thanks for the reply, but our target TTL will be ~90 days :confused:

i would try “bucket ttl”, but our server 6.0.0 and I don’t have a ttl option via create/edit bucket although mentioned in the dev. docs (maybe it’s only available on enterprise, idk).

my last resort would be a daily scheduled job to manually delete expired docs using a creationDate field… ugly but couldn’t find another way…

What I’m telling you is that it will work. Couchbase is lying to you about the TTL when you query it out of the system.

1 Like

omg :open_mouth: it worked! thanks @unhuman, its weird i didn’t encounter this on the docs. do you have any idea why i don’t have a bucket ttl option for create/update buckets settings although its on the docs?

and final question: did I get it correct that, if expiry < 30 days, it must be seconds from now, else exact epoch seconds;

int expiry = (days <= 30) ? days * 24 * 60 * 60 :;

N1QL TTL support available in 6.5.1

Pre 6.5.1 META().expiration gives value only covering index and non-covering it return 0

1 Like

Yes. You have it correct. <= 30 days = relative time, > 30 days is absolute time. You could consider just using absolute time wherever you can. Or, you can upgrade your Java client to 3.0.x and use Duration, which provides a much more consistent interface for what you’re trying to do.

As mentioned by @vsr1 it looks like you’ll be able to get implicit TTL support in N1QL with 6.5.1.

TTL is a document setting, not a feature by bucket by cluster. So, if you wanted to change your TTLs for all your documents, you would need to perform a migration activity (touching every document).

1 Like

Great, i ll try to upgrade server version then. Until then, i may try if i can use 3.x client.

TTL is a document meta as you pointed, but docs say it may be bucket wise too (but i didn’t have that opinion for my setup as i said in my previous message.

1 Like

You’re correct - looks like that’s a feature I was not aware of:

Looks like this is new to 6.x (so I don’t feel so bad for not knowing):

are you sure about that :heart_eyes: i’d be very happy to remove my ugly if block!

Yes, I’m sure. But, you shouldn’t do it because I tell you I’m sure - you have no idea who I am. :slight_smile:

But… Let’s say you want a TTL in 10 seconds. You either pass the API 10 or you pass it System.currentTimeMillis()/ 1000 + 10. Assuming your clocks are synced (and share timezone - hopefully UTC), you should be able to see your document TTL in 10 seconds either way.

1 Like

Of course i’ll test it first :slight_smile:

i thought that rule was an oblication by api, docs misguided me i guess. of course I prefer non-exceptional, a single logic to set TTL .

thank you very much @unhuman, you have been definitely helpful :pray:

1 Like