For some storage adapters, the time to live works in an unexpected way. Instead of deleting the item immediately, it only deletes the item after it has been accessed again after the ttl has expired. This is the case for the postgres adapter.
Ideally, keyv would add an api to delete all expired keys, so that we could run this as a schedule. We can try to open a PR for that, however until then, we'll add the implementation to this repository and do it by manually bypassing keyv, and direcctly accessing the database.
Alternatively, we could iterate over all items on a schedule, since this would delete expired items as well. However, this does not work well for larger databases, as it will lead to a lot of SELECT and DELETE queries.
This approach has several drawbacks:
The testing setup is not really well suited for databases
It's a very specific implementation that's not necessary for other adapters, such as redis
However, we need to regularly delete the maps, so we'll add this implementation here first.
Description
For some storage adapters, the time to live works in an unexpected way. Instead of deleting the item immediately, it only deletes the item after it has been accessed again after the ttl has expired. This is the case for the postgres adapter. Ideally, keyv would add an api to delete all expired keys, so that we could run this as a schedule. We can try to open a PR for that, however until then, we'll add the implementation to this repository and do it by manually bypassing keyv, and direcctly accessing the database. Alternatively, we could iterate over all items on a schedule, since this would delete expired items as well. However, this does not work well for larger databases, as it will lead to a lot of SELECT and DELETE queries.
This approach has several drawbacks:
However, we need to regularly delete the maps, so we'll add this implementation here first.