Allow a validation function for retrieving cached values

[jkrems]

There should be an optional validation function for get and getOrElse operation. If the data fails the validation function, it should count as a cache miss. If the validation function throws, it should count as a get error.

[jkrems]

For getOrElse the validation function should also be run on values that are to be stored.

[johan]

This is something we want too, and consider addressing in a bit, as we have a fair deal of semantically (if not technically) empty responses that take a while to flush out of our caches at the moment.

[ghost]

What if the getOrElse lambda returns null/undefined and that counts as a validation failure?

[jkrems]

null is a valid value to cache. E.g. to cache a missing value (when checking for existence is expensive). It's also about validation the value that comes from the cache - not the only the generated value.

[johan]

Am I missing something, for thinking that the current call signature (getOrElse(rawKey, val, opts, cb)) doesn't yet pass the proposed validation function, and that on adding one here, it would just return a boolean value to pass or fail the value it tests? It seems like just adding an opts.validate or something should be straight-forward.

Or is @khoomeister talking about a presenter function that lets us condense the api call value and save something parsed in the cache instead of the literal response – with overloaded behaviour semantics for letting, say, undefined signal error?

Something like that (with a clean api) would be useful too, but perhaps as its own independent feature. I have specifically wanted to cache not just the response body, but also bits from response metadata passed in subsequent callback args from request, or gofer.fetch, like what the api url was, so getOrElse could pass on as many callback args for the cached case as for the non-cached case.

[jkrems]

@johan Yes, opts.validate was what I had in mind. I'm hesitant to add something with more complex semantics than "check schema, return boolean". Especially mapping/transforming the data seems like overstepping boundaries for a caching library. The direction for everything right now is "promises", so I don't think adding features that refer to callback semantics makes sense at this point.

[ghost]

cool @jkrems, i was more concerned with how much validation functionality to include :smiley: - your proposed interface sounds good to me.