lucid
lucid copied to clipboard
lucid-kv
[Manifest] About Expiration
Hi,
About object expirations, what do you think @CephalonRho? We have two ways to proceed:
- Make a loop in a separated thread and drop items when the time is due.
- Check the expiration date when a GET is called and drop the object if it's expired.
Best regards
I think the second option should be the first step of implementing this. Regardless of any other optimizations such as dropping them in the background, a client should never be able to access an entry after it has expired, so there should be a check every time the entry is accessed.
Shouldn't be a big problem to implement the actual expiration part of this, I'm more concerned about how we want to set the expiration time. A way to set individual lifetimes on entry creation would be good, but we probably also want to have default lifetimes for everything and a way to change entry lifetimes after creation (probably with PATCH when that happens).
Happy new year! 🍾
Something like this is a possiblity, but it's also possible with an http header like X-Expiration.
curl -X PATCH -d 'ttl=3600' https://localhost:7021/api/kv/hello_world/
I also think that a way to specify expiration at the creation is a good and needed things!
Anyway we need to achieve the PATCH part and also determine if we use JSON or other.
Didn't think about http headers, definitely a good option here. Discussion about the PATCH method belongs in https://github.com/lucid-kv/lucid/issues/44, but it's not a requirement for entry expiration anyway as long as there is another way to set them. I would use headers to set the TTL when creating entries and keep PATCH completely separate with it's own format, whatever that will be.
TTL and expiration is not really the same things, I mean we also need to define if we use TTL or an absolute expiration datetime (by example with a timestamp) or maybe the both?
The expiration will be also a problem for the persistence, but we will see that in the proper issue (#17)