Open JaredReisinger opened 7 years ago
Full disclosure: I'm writing a cache-service-file-system module for cache-service to have file-system-backed persistence for superagent, and also to use for a really cheap persistent data store... no dependencies on redis or memcached required, data is easily human readable and easily programmatically consumable by other tools. Also, my calling code is promise-based, so I expect for my .then()
chains after a .set()
to only happen after the data has been written to disk. (If I didn't have that requirement, I wouldn't put the following code in the .then()
, I'd just continue immediately after calling .set()
.)
This is a proof-of-concept PR for the issue raised in https://github.com/jpodwys/cache-service/issues/22. In particular, the caller-provided callback is only called when all of the cache modules have completed.
In making this change, I discovered several other issues that should probably be addressed.
In general the cache-service "writing" APIs (
.set()
,.mset()
,.del()
, and.flush()
) don't define what the caller-provided callback will be passed on success, failure, or partial failure. (I suspect cache-service will need to define something like an "aggregate error" to encapsulate the "one or more modules had a problem" scenario.)The
.get()
API implies (by "response... null on cache miss") that a cache miss should not pass an error value to the callback; this should likely be explicit. On the other hand, cache-service's implementation handles module.get()
errors by simply trying the next module, so perhaps cache-misses should be handled by an error value, allowing any value (including null and undefined) for a cache-hit.The module API doesn't specify what should be passed to the callback on success or failure. Is only the
err
argument used? Is nothing inspected, and the callback used only to indicate completion?