New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PSR Cache Proposal #96

Closed
wants to merge 52 commits into
base: master
from

Conversation

Projects
None yet
@dragoonis
Member

dragoonis commented Mar 12, 2013

Quick Link: https://github.com/dragoonis/fig-standards/blob/master/proposed/psr-cache.md

note: the examples section in psr-cache.md will not be part of the official proposal, it is just here so that everything is under the one hood and to prove that the interfaces are solid.

@evert evert referenced this pull request Mar 12, 2013

Closed

Proposal for an object cache #11

ashnazg and others added some commits Mar 12, 2013

@AmyStephen

This comment has been minimized.

Contributor

AmyStephen commented May 18, 2013

By the way, interested in seeing your solution. Been thinking more and more
we are heading towards Data Mappers sitting in front of a lot of this.

On Sat, May 18, 2013 at 2:41 PM, Amy Stephen amystephen@gmail.com wrote:

Remember, this is only an interface. Meaning, a developer has to create a
handler for each type of cache that is supported. The adapter is
instantiated and the selected handler injected via the constructor. So,
it's not possible to avoid a customized handler - that's the intention.

Now, in the case of an automatic key, curious, how does the cache get
retrieved? (How does the developer know what to use for a get key?) Reason
I ask is the only issue I can see that might be a problem is if sending in
a value for the key is impossible for the set.

If you can explain a bit on how the cache is retrieved, that would help.

On Sat, May 18, 2013 at 1:53 PM, Noah Goodrich notifications@github.comwrote:

@AmyStephen https://github.com/AmyStephen and @bobthecowhttps://github.com/bobthecow

I maintain a stand-alone Data Mapper that utilizes the increment()
functionality in memcache. I'm looking at the standard from the viewpoint
of a library that will consume PSR\Cache implementations as drop-in
replacements without requiring customization.

This standard doesn't do much good if everyone who uses my Data Mapper
library has to customize their chosen Cache library. As such, I wonder what
the standard will be for libraries that use a cache library implementing
this standard if increment() is a required function?


Reply to this email directly or view it on GitHubhttps://github.com//pull/96#issuecomment-18106147
.

@noah-goodrich

This comment has been minimized.

noah-goodrich commented May 18, 2013

@AmyStephen

https://github.com/energylab/gacela/blob/master/library/Gacela/Gacela.php

The important bits are the enableCache(), _cache() and incrementDataCache() methods.

Originally this was all written to just use the Memcache library, but I'm looking at this PSR as a way to allow someone using Gacela as their Data Mapper to drop in any Cache library and just run with it.

Right now if you look at my docs, the requirements for enabling a cache are as follows:

Gacela will use any caching library that supports get(), set(), and increment()

With this PSR as an available standard, my requirement would become any caching library that supports the PSR-Cache standard. Make sense?

As for the keys, the singleton cache instance is used in the DataSource\Adapters to store metadata for the specific data source. Or in the Mapper\Mapper class if caching is enabled for a concrete mapper class. In both cases the keys are basically hashes implemented within the context of the framework and the developer never interacts directly with the cache.

@AmyStephen

This comment has been minimized.

Contributor

AmyStephen commented May 18, 2013

@noah-goodrich As an FYI, if you want to look at one, here's my Cache Adapter/Handlers with the draft PSR Interfaces https://github.com/Molajo/cache - you are right, if increment is a critical feature of your application, the PSR would not be enough.

You probably should request the addition in this thread https://groups.google.com/forum/#!topic/php-fig/lANQM7LPX_M - Although I'm not sure if that will help or not, the project is in a weird spot.

If it doesn't get included, you can work with developer(s) providing the library, ask them to add increment, I wouldn't have a problem adding that if it helps. Or you can fork their library, do it yourself and include it. We're going to have to collaborate while these PSR's get rolling.

@jfsimon

This comment has been minimized.

jfsimon commented May 19, 2013

I think increment() should be part of the interface too.

If I build a library based on the cache and I use PSR/Cache, I will only rely on the interface for interoperability. If I have to increment/decrement interger value I will have to reimplment these methods with get() + set(). It's a performance issue (2 requests instead of 1). Caching is all about performance.

Of course, interface is the "minimal contract" of the backend which could implement these methods, but if I have to check if backend class supports or not incrementing, the interface does not fulfill its role.

Furthemore, calling increment() with a negative argument looks really weird to me, so I think decrement() should be part of the interface too.

@Crell

This comment has been minimized.

Contributor

Crell commented May 19, 2013

Once again, this discussion belongs on the FIG list, not in a GitHub thread where most people won't see it. We're discussing the cache PSR there now anyway, so this is the time to bring it up.

@jfsimon

This comment has been minimized.

jfsimon commented May 19, 2013

@Crell sorry.

@empire

This comment has been minimized.

empire commented May 19, 2013

@AmyStephen , @jfsimon @noah-goodrich I think we can have some other interfaces for making increment happen, some thing like following

inteface IncrementableItemInteface 
{
    public function increment($value = 1);
}

And then, for some cache engine, we can have CacheItem class that implements IncrementableItemInteface, we can check just by instance-of

   public function workOnSomeItem(CacheItem $cacheItem)
   {
       if ($cacheItem instanceof IncrementableItemInteface) {
             $cacheItem->increment(123);
       }
    }
@jfsimon

This comment has been minimized.

jfsimon commented May 19, 2013

@empire you should publish your response on the mailing list: https://groups.google.com/forum/#!topic/php-fig/lANQM7LPX_M ;)

@empire

This comment has been minimized.

empire commented May 19, 2013

@jfsimon thanks, I post it.
In hope that will be useful.

use Psr\Cache\ItemInterface;
interface CacheInterface

This comment has been minimized.

@moisadoru

moisadoru Jun 2, 2013

I think a better suited name for this interface would be Psr\Cache\SingleAccessStore (or something similar), to clearly denote the fact that you can only get/set single items.

```
### 2.3 MultipleInterface

This comment has been minimized.

@moisadoru

moisadoru Jun 2, 2013

I think a better suited name for this interface would be Psr\Cache\MultipleAccessStore (or something similar), to clearly denote the fact that you can access multiple items in a single call.

*
* @return boolean The result of the multiple-set operation
*/
public function setMultiple($items, $ttl = null);

This comment has been minimized.

@moisadoru

moisadoru Jun 2, 2013

How does one set individual TTLs for $items ?

### 2.4 IncrementableInterface
This interface provides the ability to increment and decrement cache entries by their specified value. Some cache backends support this natively so that you don't have to read the item and then increment it and write it back to the cache server, this can be done in a single call to the cache server since it's natively supported by many modern cache servers.

This comment has been minimized.

@moisadoru

moisadoru Jun 2, 2013

What is the behavior when trying to increment/decrement an entry that is not numeric?
Ex:

$cache->set('foo', 'bar');
// ... later in the code:
$cache->increment('foo', 1);
// or
$cache->decrement('foo', 1);
@dragoonis

This comment has been minimized.

Member

dragoonis commented Jun 25, 2013

Closing this PR.

@dragoonis dragoonis closed this Jun 25, 2013

@Alan01252

This comment has been minimized.

Alan01252 commented Jul 31, 2013

Just out of curiosity any reason why this was closed? I personally think this would be a useful standard.

@philsturgeon

This comment has been minimized.

Contributor

philsturgeon commented Jul 31, 2013

This specific PR has been closed to make way for #149

@dave1010

This comment has been minimized.

Contributor

dave1010 commented on 1453a9c Nov 6, 2013

This gist looks like APC, not Memcached. Do you have a Memcached version?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment