how to handle expired mechanism

[beatwade]

as cookie expired time for auth and privacy info,
how about other storage api? there is a away to auto handle expired value?

[gruns]

I'm afraid I don't understand exactly what you mean.

Do you want the ability to set an expires date for a key? E.g.

import { IronDB } from 'iron-db'

await IronDB.set('key', 'value', { expires: 7 })

?

[beatwade]

@gruns yes, exactly right, I'v quickly found the repo test case, and can't found a way to get the expires date feature. do I miss something?

[gruns]

ImmortalDB currently doesn't support expires metadata. That would be a useful
feature, though.

I'll add it shortly. Or, conversely, pull requests welcome.

The right API for this is an additional, optional options object parameter to
the set() method. Like

IronDB.set(key, value, { options })

E.g. the aforementioned

await IronDB.set('key', 'value', { expires: 7 })

[alienriver49]

I wrote an internal store heavily based off ImmortalDB (I didn't go with this library since it doesn't allow the setting or providing of the DEFAULT_KEY_PREFIX and I wanted developers to be able to create multiple stores) and I got a similar request from one of our developers.

The way I was going to go about it was adding the expires to the store config instead of the set method, but for ImmortalDB it probably makes sense for the set method since it doesn't have a store config and for my case I may also allow it on the set method in the future. One of the problems becomes that where do you store the expires information? Since you could have an expiration longer than the time the user will have the application open.

My solution was going to be to store expiration information for keys at internal key (not usable by consumers, i.e. _immortalExpirations) within the store itself (ImmortalDB in this case). Then ImmortalDB would do this loading of expiration as part of it's onReady initialization. Then whenever a get is performed it would check against the loaded expiration information to see if the data is expired, if so it would delete the key and return null. Similarly, set would update the expiration information and restore the updated information. Finally, remove would remove the expiration information and restore the updated information.

Figured it was worth sharing since it's a similar problem. It's nice too because you get to "eat your own dog food" by using the store to store expiration information. When I implement it for our store (sometime next week), if I think it's applicable to ImmortalDB I may submit a pull request.

[gruns]

When I implement it for our store (sometime next week), if I think it's
applicable to ImmortalDB I may submit a pull request.

@alienriver49 Quick follow-up here: is it easy to create a PR for ImmortalDB?

(I didn't go with this library since it doesn't allow the setting or providing
of the DEFAULT_KEY_PREFIX and I wanted developers to be able to create
multiple stores)

This is a useful tidbit itself. I'm breaking this off into a separate Issue.

[alienriver49]

@gruns I think it would be pretty easy to create a PR for ImmortalDB, let me see if I can get that in. It's been a while since I was in the project where we were implementing the store, but should be able to get something.

This is a useful tidbit itself. I'm breaking this off into a separate Issue.

That would be awesome!

[cedriking]

Hello, I created a new PR for the expiration mechanism.
Yesterday I found ImmortalDB and it's an amazing project, good work!

#49