Cache Standard Interface #17
Conversation
This is the initial outline of the caching proposal, including the interfaces themselves (which are the most fleshed out part of this being added to the repo at the moment).
This will allow people to actually use the interfaces.
…eIteratorFactory interfaces.
Changed some of the formatting around, added the "Multiple" section.
…(redundant) "Cache".
Extensively expanded the proposal. Added the new interfaces (with comments), wrote out the introduction and data sections, and cleaned up a lot of formatting.
Clarified that the clear function should return true as long as the item is not in the cache at the end of the call, regardless of whether it was removed or never existed.
Clarified acceptable keys, clarified that null should explicitly be null, altered header names, added text for namespaces, added the TaggableItem interface, and removed the driver interface.
By merging the two classes into one we create more of an environment class, which makes certain extensions significantly easier to architect simply.
…d the Stackable class.
Ran through and made sure all class names were correct and fixed some misspellings. Cleaned up the interfaces a bit, and then brought their new comments back into the main proposal.
php opening tags for syntax highlight
fixed typo
Signed-off-by: Norv <[email protected]>
php tags in Extensions interfaces.
…ting caching system.
This was brought up on the mailing list and seemed like a reasonable idea. It also will make it easier for implementing libraries to use one class for systems that use stackable and non-stackable components, making it easier to segment the two pools (internal namespacing or something) as there will *always* be a slash when Stackables are used.
Updated the Stackable keys to have them start with a root slash.
…system. Added php tags. Signed-off-by: Norv <[email protected]>
Clarification on Item::set()
…che" As discussed on the mailing list, there may be some confusion over the "getCache" and "getCacheIterator" functions since there is no actual cache object. By changing them to "getItem" and "getItemIterator" we make it much more clear what is actually returned.
Updated the names of the "get" functions to use "Item" instead of "Cache"
| * | ||
| * @return bool | ||
| */ | ||
| function isMiss(); |
There was a problem hiding this comment.
Almost all validators I've seen pass with a positive result, so I'd prefer to see this as isValid, isAvailable, etc.
There was a problem hiding this comment.
+1 : if (! isMiss) is less readable than if (! isAvailable) (avoid double negatives)
There was a problem hiding this comment.
BTW I realize that you chose isMiss because most checks would be testing for a fail before regenerating the cached value, but I still think it looks funny in the interface.
There was a problem hiding this comment.
I'm in agreement here. The isValid() or isAvailable() are much closer to what I'd expect from the proposal. @tedivm can you please update your PR to make this a true check rather than a false check?
There was a problem hiding this comment.
Is here a preference? I'm thinking "isValid" is better than "isAvailable".
There was a problem hiding this comment.
I'm not a big fan of exists, as whether an item exists or is valid are really two separate questions. The "get" function may be able to return a value that exists, but is past it's ttl and therefore no longer valid, at which point the developers using the library needs to make a decision about what they'd like to do. In most cases they'll treat validity and existence as the same, but that won't always be the case.
There was a problem hiding this comment.
Well if it's expired IMO it shouldn't exist anymore, it should be a
cache miss.
There was a problem hiding this comment.
IMO it shouldn't be possible to get a cache entry that expired.
Edit: I agree with @Seldaek
There was a problem hiding this comment.
90% of the time you're right, but I don't think we should exclude the 10% time when it's reasonable. There are many, many cases where it's more valuable to use a stale value (presumably while another process is regenerating the proper value), rather than enter a stampede (aka the dog pile affect) or pause to wait for the value to return.
Keep in mind this isn't saying get has to return anything- it doesn't. What this is saying is that the option is there for a library to expand it's functionality within the scope of this proposal. If a library wants to have a "standard" Pool and Item class, but also wants an extended Item class that handles validation differently (such as by doing any of the following- http://stash.tedivm.com/Invalidation.html ) then this standard should not get in their way.
The extensions were removed so the focus could be on the core standard. Should this standard pass they'll be brought up for discussion and vote on their own.
|
Shall we include Compare-And-Swap concept? http://neopythonic.blogspot.nl/2011/08/compare-and-set-in-memcache.html |
Accidentally tossed an old PSR in here when merging with the main fig-standards branch.
This was based off of Paul's suggestion in the mailing list, and tries to make the function call more intuitive.
This change was made to provide clarity, as some libraries use "flush" to mean "save changes" which is pretty much the opposite of what's happening here.
Added "Key Concepts" section to help explain naming conventions.
Value should be able to be set to null.
Use clear instead of empty as empty is a reserved word.
|
This proposal has been superseded by #96. Please continue discussion over on the mailing list topic. |
Proposed is a set of interfaces for a basic cache system, as well as extensions that can be used to build upon it. The goal of this PSR is to allow developers to create cache-aware libraries that can be integrated into existing frameworks and systems without the need for custom development.
Conversation has occurred on the list with regards to this, but additional discussion and PR's is highly encouraged.