Semantics of get() on cache miss about cache

[WyriHaximus]

What would you expect in this situation @jsor? That behavior makes perfect sense to me, and I'm using it extensively for flow control in applications/packages.

[jsor]

The correct implementation in ArrayCache would be:

public function get($key)
{
    if (!isset($this->data[$key])) {
        return Promise\resolve(null);
    }

    return Promise\resolve($this->data[$key]);
}

Rejection means that an error occured, eg. in the underlying storage system.

In case of the WyriHaximus/reactphp-cache-redis implementation, rejection should only happen when the redis client reports an error, eg. https://github.com/clue/php-redis-react/blob/master/src/StreamingClient.php#L90 because this is then a bug in your application.

The implementation should be something like

public function get($key)
{
    return $this->client->exists($this->prefix . $key)->then(function ($result) use ($key) {
        if ($result == false) {
            return null;
        }

        return $this->client->get($this->prefix . $key);
    });
}

And used like

$redisCache->get('foo')->then(
    function ($result) {
        if (null === $result) {
            // cache miss
            return createAndStoreAndReturn('foo');
        }

        return handle($result);
    },
    function (\Exception $e) {
        call('WyriHaximus')->andTellHim('Theres a bug in your application or the redis server is down');
    }
);

[kelunik]

+1 for returning null on miss. Works well with ??.

[jsor]

An alternative approach would be to reject with an exception on cache miss. This way, a cache miss can be handled differently than exceptions thrown from the underlying storage system (requires react/promise ^2.0).

$cache->get('foo')
    ->otherwise(function (CacheMissException $e) {
        return getFromDB('foo');
    })
    ->otherwise(function($e) {
        log($e);
    })
    ->then('var_dump');
;

[kelunik]

@jsor If a cache miss returns null and an issue in the underlying storage system throws an exception you can differentiate that as well. And you don't have exceptions for non-exceptional code paths.

[jsor]

@kelunik You don't have to convience me, i've opened that issue ;)

[clue]

I agree that returning null makes sense here as this clearly isn't "exceptional" 👍

[WyriHaximus]

Work in Progress PR up at #22