PSR-6: Cache

[Crell]

Pull request for a Caching PSR. This summary will be updated with the current status periodically.

Status

The current text can be found here:
https://github.com/Crell/fig-standards/blob/Cache/proposed/cache.md
https://github.com/Crell/fig-standards/blob/Cache/proposed/cache-meta.md

Please discuss any proposed changes on the mailing list before filing a pull request against this branch.

To participate

• Please do not discuss details of this PR as a PR! I know it's weird, but that's the way FIG works these days. :-)
• To discuss a specific section, comment on the FIG mailing list in the thread specifically for that section.
• To request a specific change based on discussion on the mailing list, open a pull request against the Crell/Cache branch from your own fork. Please do not open PRs that have not already been discussed at least briefly on the list.

[philsturgeon]

How does a pool object create the item object? I don't see any sort of factory method.

[tedivm]

Pool->getItem is the factory method. It creates Items and sends them back out.

[philsturgeon]

Gotcha. If I got confused on this maybe others will too. Can you shove in a note about that?

They may only be created by a Pool object via the getItem() method...

Or something.

[tedivm]

I agree, that's a good call.

[rande]

Why the $key element must be a string? this will create so much restriction on how we can flush a cache item. If the key can be a array, then this can be used by storage engine like redis or mongodb. If the backend storage cannot handle the array, it can serialize it with its own way.

so on the dev's user point of view, we only have the key and not the final key used by the backend engine.

$key =  ['post_id' => 3, 'image_id' => 4];
$storage->save($item, $storage->get($key)->set('myValue'));

$key =  ['post_id' => 3, 'image_id' => 4];
$storage->save($item, $storage->get($key)->set('myOtherValue'));

$storage->remove(['post_id' => 3]); // will remove the 2 items from the database.

The usage of a Key(string) => Value is a legacy representation of memcache/apc system. There are now other system with more advanced options.

[philsturgeon]

Notice getItems() and deleteItems() below. They will take care of your use-case.

[rande]

@philsturgeon no, as the full keys provided must be ['post_id' => 3, 'image_id' => 4] and ['post_id' => 3, 'image_id' => 4] in my example. What I want, is a way to remove all caches items with post_id => 3.

[philsturgeon]

@rande Ah, gotha. I misunderstood when you were talking about:

The usage of a Key(string) => Value is a legacy representation of memcache/apc system. There are now other system with more advanced options.

You are of course entirely right, that Key(string) => Value is an old concept, and other more advanced features exist for a variety of different caching systems out there, but the point of this PSR-6 Cache is to provide a standard interface for the basic aspects.

There will be various Redis or Mongo features that people will want, but we could hardly add those in to a basic caching standard, as how would that work for systems that don't support those new features?

Getting, storing and deleting items by their key (or an array of keys) is incredibly common, and IMHO will be the vast majority of what people are doing when they want to work with a cache interface. Other implementations will always add other features on top of the standard, and these extra features will be what we consider for a more advanced cache system in the future.

We're not meant to really discuss these things on GitHub as its unfair for people who do not follow the discussion notifications. So, if you think my explanation there is unfair/unreasonable/whatever then feel free to make a thread on the mailing list. It's my opinion that this feature request should not be in this spec, but you can easily just ignore me and take it to the mailing list. :)

[tedivm]

Just to add to this, we have an "advanced" caching proposal that we've been pushing off until after the basic one has resolved. In that one we'll be able to throw in interfaces that only fit certain "types" of caches, so that features can be typehinted against through those interfaces and people can use some of the advanced functionality.