Cache Expiration

[dreymonde]

Cache Expiration

[dreymonde]

Hi @nmccann! Thanks for your thoughts, I really appreciate it.
I’m having a day off now, but I’ll get back at Sunday to discuss this very interesting question at length. So stay tuned! 🙂

[dreymonde]

Okay, I’m here now.
Cache expiration is, of course, a very useful and reasonable requirements for many apps, but it’s implementation is way too opinionated to be included in the library — I view Shallows as a toolbox that doesn’t perform any kind of dark magic under the hood.

As for the implementation itself, I think it can be done pretty easily. Here’s what I came up with:

final class LeastRecentlyUsedStorage<Key : Hashable, Value> : StorageProtocol {
    
    let storage: Storage<Key, Value>
    let metadata: Storage<Void, [Key : Date]>
    
    init(storage: Storage<Key, Value>, metadata: Storage<Void, [Key : Date]>) {
        self.storage = storage
        self.metadata = metadata
    }
    
    func retrieve(forKey key: Key, completion: @escaping (Result<Value>) -> ()) {
        storage.retrieve(forKey: key) { (result) in
            self.metadata.update({ $0[key] = Date() })
            completion(result)
        }
    }
    
    func set(_ value: Value, forKey key: Key, completion: @escaping (Result<Void>) -> ()) {
        storage.set(value, forKey: key) { (result) in
            self.metadata.update({ $0[key] = Date() })
            completion(result)
        }
    }
    
}

As you see, it showcases what I love about Shallows — you actually don’t know pretty much anything about where or how the values are stored, you only declare the logic of LRU component. It also doesn’t perform any kind of cache clearance itself, but you can write a simple extension to simplify this process:

extension LeastRecentlyUsedStorage {
    
    func keys(usedEarlierThan date: Date, completion: @escaping (Result<[Key]>) -> ()) {
        metadata.asReadOnlyStorage()
            .mapValues(to: [Key].self, { meta in
                let filtered = meta.filter({ key, value in value < date })
                return Array(filtered.keys)
            })
            .retrieve(completion: completion)
    }
    
}

And do any kind of logic needed outside the LeastRecentlyUsedStorage object.

Ping me if you have any questions!

[nmccann]

That is a very nice solution! And yes, I agree that it would be difficult to come up with something that would handle all possible cases - better to give users the equipment needed to implement it themselves. While a specialized solution may give better performance/more compact storage (for instance, by storing the access date in extended file attributes), it would be so specialized that it might be impossible to mix with any of the other tools in your toolbox analogy.

One question I do have: Is there any particular reason why your metadata property is of type Storage<Void, [Key : Date]> rather than Storage<Key, Date>?

[dreymonde]

@nmccann

...it would be so specialized that it might be impossible to mix with any of the other tools in your toolbox analogy

That’s very true! That’s a tricky balance for sure, but I mostly try to keep my structures abstract.

Speaking of metadata — well, the only reason to have that Storage<Void, [Key : Date]> is to have the ability to iterate over keys.

[nmccann]

Ah I see, because StorageProtocol only has methods for getting/setting one key at a time. Maybe that would be something useful for the toolbox - an IterableStorageProtocol. That said, providing implementations for all of the existing storage types would add a lot of extra surface area to the codebase when you could just use the workaround of Storage<Void, [Key : Date]>.

In any case, I think we can close this issue. Thank you for your help!