Check if a key is in the cache, remove a key from the cache

It would be nice if the LINQPad cache allowed the following operations:

* Check if a string key is in the cache. Perhaps "bool Utils.CacheContains(string key)"
* Delete a cache item by key, if it's in the cache and indicate whether it was ["bool Utils.RemoveFromCache(string key)"]
* Get an item from the cache by key if it's in there ["object Utils.GetFromCache(string key)" returning null if not found?]

The LINQPad cache is very useful, but sometimes its behaviour is non-obvious (why did my stuff "disappear" from the cache just now? or did it?") These methods would help in troubleshooting it and possibly in other scenario.


  • I agree that this would be useful - for one of my scripts, I ended up writing my own caching functions using AppDomain.CurrentDomain.GetData / AppDomain.CurrentDomain.SetData, especially because I wanted to show the value in the cache and allow the user to edit it and overwrite the value.
  • what are your thoughts on this @JoeAlbahari ? :)
  • edited June 2016
    EM0 - are you aware of the Util.Cache overload with fromCache? This lets you know whether the item was fetched from the cache.

    To answer your other question, stuff disappears from the cache when the process is recreated, which happens if you cancel a running query and LINQPad has to abort the thread. It can also happen if the memory footprint gets too high.

    Do you have any other reason for needing these functions?

    kingkeith - in what way would additional caching methods be better than what you're doing now, with Application.GetData/SetData? LINQPad's Cache method can be thought of as a wrapper over Application.GetData/SetData, with a signature designed for the performance-optimizing scenario (essentially like Lazy of T).

    LINQPad's Cache method also does automatic serialization/deserialization and anonymous type shredding for objects whose types are recompiled, but I don't imagine you'd be relying on this for user input.

    Do you want a version of Util.ReadLine that automatically remembers / restores the default value?
  • edited June 2016
    Do you want a version of Util.ReadLine that automatically remembers / restores the default value?
    Yes please Joe - that is exactly what I am after! :)

    For me, it would be fine if it used the "prompt" as a key for the cache.
    It would also be great, if possible, for the "suggestions" to include those cached from previous inputs too, if that makes sense.

    var hostname = Util.ReadLine(prompt: "Host name", initialDefault: "localhost", initialSuggestions: new [] {"Neptune", "localhost"})

    First run, it is pre-populated with localhost, and suggestions "Neptune" and "localhost". User types Jupiter.
    Second run, it is pre-populated with Jupiter, with suggestions: "Neptune", "Jupiter" and "localhost". User types Saturn.
    Third run, it is pre-populated with Saturn with suggestions "Saturn", "Jupiter", "Neptune" and "localhost".

  • Yes, I know about the overload with "fromCache", but this requires me to pass in a function to load the data if the key is not in the cache. So I either have to pass in the real function to load the data or a fake function. The real function is slow and a fake function would cause the cache to contain wrong data if the key wasn't in the cache before. Given that I can't remove a key from the cache, either, this doesn't work as a good way of checking if the key is in the cache or not.

    It's good to know how LINQPad is supposed to work, but this isn't a replacement for knowing whether a key is ACTUALLY in the cache right now. That's what GetFromCache() would be for. CacheContains() would cover the case where the cached value is null (rather than the key not being in the cache). RemoveFromCache() would help where I have multiple cached values, each of which took maybe 10 minutes to compute and I want to re-compute just one of them.

    The reality is that software often doesn't work like it's supposed to :) and that's where troubleshooting tools like this become valuable.
  • Did what we discussed ever get implemented?
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!