Community Questions

[dragoonis]

No description provided.

[dragoonis]

Should Increment / Decrement be part of the SimpleCache spec?

[dragoonis]

Should Multi Get / Set / Delete be part of the SimpleCache spec?

[dragoonis]

Should the exists() method be part of the SimpleCache spec?

[Seldaek]

To all those voting no, I do wonder why? Those are all pretty trivial to implement for cache implementors, and they do provide substantial value in terms of performance (multi*) and just outright being able to implement things that would not be possible otherwise (incr/decr).

Not having them sucks in some cases, and adding them is cheap on the implementation side and can only benefit on the user side, so why not have them?

[mlebkowski]

@Seldaek, because atomic inc/dec can be problematic for drivers, what then? Use non-atomic operation or fail? That’s not a simple interface anymore (IMO).

[Seldaek]

@mlebkowski IMO if you use a driver that doesn't implement these, then you don't have an application load in which the atomicity matters anyway, so if the driver lies and isn't atomic it's probably not a huge deal. If you have any kind of real concurrency needs you really want to use memcache or redis, not some half-baked filesystem implementation. The point is the interface defines it as atomic and users should assume it is, if you then configure a driver that isn't following the interface strictly that's your problem.

[mlebkowski]

@Seldaek, I think you should add this comment to the spec and it would clear things out. If it would be described as "preferably atomic but with a fallback allowed" operations then sure — there is no cost in implementing them as set(get()+1), only a possible benefit. I would vote 👍 for that.

[marcj]

Should Increment / Decrement be part of the SimpleCache spec?

No, because it has nothing nothing to do with a) a cache system in general an b) with a SimpleCache version. Cache is about to avoid re-computation in a temp storage. inc/decs makes the storage non-temp anymore and has nothing in common with the idea of jump over re-computation.

Should Multi Get / Set / Delete be part of the SimpleCache spec?

No, because this is nothing people use mostly. Thus, it shouldn't be included in the "Simple" cache.

Should the exists() method be part of the SimpleCache spec?

No, because it leads to race-conditions. if ($cache->has($key) { $cache->get($key); //boom }

[dragoonis]

@marcj as for exists() - it's documented when to/not to use this method. https://github.com/dragoonis/fig-standards/blob/psr-simplecache/proposed/simplecache.md

[marcj]

@dragoonis ah, seems legit :)

[bwoebi]

Should Increment / Decrement be part of the SimpleCache spec?

No, not really. What could be done is an interface extending it providing locking and fundamental atomic primitives. It's outside the scope of simple cache. Most simple caching (i.e. store a compiled template. Prevent recalculating of something based on a static dataset), does not need that. (At the very least, if you have atomic functions, you also should have locking IMO.)

Should Multi Get / Set / Delete be part of the SimpleCache spec?

As separate methods, not so much, but you might make the simple get/set functions allow to also be passed arrays and Traversables.
[I'm a proponent of merging "multi" functions which literally just iterate over the argument and call the master function with its values into a single function. It leads to a tidier API and less functions to memorize.]

Should the exists() method be part of the SimpleCache spec?

No; this has the advantage of being able to have del($key) and set($key, null) semantically equivalent. (We might even drop del then, but it's perhaps an useful shorthand.)

This leads us to use null as value for inexistence. Sure, you may want to allow negative caching; but in this case the user can just use a placeholder like an empty array (or whatever fits in the specific case).

[bwoebi]

@dragoonis If exists() is meant for cache warming, why can't we just check against get() returning null?

[marcj]

Btw, related long discussion in PHP-CDS: initial php-cds/php-cds#7 and further discussion in php-cds/php-cds-discussion#4

[dragoonis]

The comments around Increment / Decrement have been listened to and the compromise is that a CounterInterface has been made and those methods now live there. This will allow applications that need such functionality to use it, as it's very important to do it atomically, and applications that don't care for it, don't have to.

[bwoebi]

@dragoonis I still think the separate interface shall then offer complete functionality including locks etc. It's rare that you only need counting.

[dragoonis]

@bwoebi exists() isn't the same as get() !== null. You have to transfer the payload over the network from server->client, and then unserialize() the payload into PHP objects, consuming CPU and MEM overhead too, just to look inside a box and see if something is there? This is why all popular caching libraries (Zend / Doctrine) and all the caching drivers (apc,memcached,redis..etc) ship with exists(). It doesn't deserve its own Interface and will be part of the CacheInterface.

[bwoebi]

@dragoonis Typically, you only initialize something you need in the current request. You anyway have to fetch the data over the network in these cases.

It is pretty much an edge case where you don't need it. I'm not even aware of any cases (apart from non-real world made up cases) where it isn't the case that you initialize something you don't need in that same request.

[cryptiklemur]

I voted yes on multi, but no on inc/dec.

I'm not sure inc/dec belongs in a SimpleCache implementation. Simple should just be get, set, exists, and maybe delete (could be done with setting no value).