A modern programming language that makes developers happier.

kotlinlang

Hello,
is there an ability or possibility in the roadmap to automatically delete/purge a setting when the size is larger than something or if the value is inactive after a while? or maybe delete old data like the LRU algorithm?

My problem is that we use a source of truth and can't find a way how and when to delete the data? I mean, if there is an ability to set the expiry or size of source of truth.

your comments mean a lot :D
thanks

Hey there - No this isn’t on our roadmap. I think the responsibility of managing eviction of SOT data should be handled by the underlying SOT rather than the Store lib. Store does have the concept of a `validator` . The `validator` checks local data before emitting it and refreshes the data when it’s not valid

Do you have any suggestions on how to proper manage the eviction of SOT data?

My understanding is we can have any logic and when we want to clear the data we only call `store.clear("key")` .. Is it correct?

Also, in the store example, there is a `ttl` but I don't see when the data should expire and delete the data from SOT?

I mean, there is no relation between `ttl` on the validator and data eviction.  `Ttl` is only being used to decide want to use data from SOT or not. CMIIW

&gt; My understanding is we can have any logic and when we want to clear the data we only call `store.clear("key")` .. Is it correct?
Yes. You can use `store.clear("key")` to manually remove data for a specific key from both the memory cache and SOT. This is useful when you know that a particular piece of data is no longer needed or should be refreshed.

&gt; Also, in the store example, there is a `ttl` but I don’t see when the data should expire and delete the data from SOT?
&gt; I mean, there is no relation between `ttl` on the validator and data eviction.  `Ttl` is only being used to decide want to use data from SOT or not. CMIIW
In that example, `ttl` is used by `validator` to determine whether to serve data from the SOT or fetch fresh data. Fetching fresh data replaces the stale data for the associated key.

&gt; Do you have any suggestions on how to proper manage the eviction of SOT data?
If you want to automatically evict data from your SOT based on a TTL, you’ll need to implement that logic within the SOT itself.

For example, if you’re delegating to Room for your SOT, you could:
1. Add a  `@Query` annotation and a timestamp field. Periodically delete stale data from a WorkManager job.
2. Use Room’s `maxSize` parameter when creating your database. Room will automatically remove older data to stay under the limit.
How you manage data eviction will depend on your particular needs. But in general, the Store lib is designed to work in conjunction with your chosen SOT, not replace its functionality.

Understood. thank you for the explanation mate :cheers: :+1:

We used to have a concept of record providers for source of truth in store3. It would let you return a record state for example stale <https://github.com/nytimes/Store/blob/d810395e05f177f195e9808914f24aa70e622fcd/filesystem/src/main/java/com/nytimes/android/external/fs3/FileSystemRecordPersister.java#L57|https://github.com/nytimes/Store/blob/d810395e05f177f195e9808914f24aa70e622fcd/filesystem/src/main/java/com/nytimes/android/external/fs3/FileSystemRecordPersister.java#L57> maybe we should add to store5 and have a record type that auto calls delete for the key 

<https://github.com/nytimes/Store/blob/feature/rx2/store/src/main/java/com/nytimes/android/external/store3/base/RecordState.java|https://github.com/nytimes/Store/blob/feature/rx2/store/src/main/java/com/nytimes/android/external/store3/base/RecordState.java>