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.
* 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.
Comments
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.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?
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.
i.e.
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 typesJupiter
.Second run, it is pre-populated with
Jupiter
, with suggestions: "Neptune", "Jupiter" and "localhost". User typesSaturn
.Third run, it is pre-populated with
Saturn
with suggestions "Saturn", "Jupiter", "Neptune" and "localhost".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.