|Timestamp||Your name||Which model (as described above) should FIG pursue?||What is your reason for favoring that approach?||Are you a voting member of FIG?||What project do you represent?||Should we address multi-operations (multi-get, multi-set, multi-delete) in the base PSR-6 definition?||How should we handle set() vs. save() actions?||What is your reason for favoring that approach?|
|9/1/2013 18:56:42||Larry Garfield||It's trivial to emulate in user-space, so let's get 'er done now and have a more robust and reliable baseline.||Yes||Drupal||Yes, as a required feature||We should have a separate save() method from set(), so that all setters may be called in any order||SRP applies to methods, too.|
|9/2/2013 2:56:23||Gábor Fási||No||Symfony||Yes, as a required feature||We should have a separate save() method from set(), so that all setters may be called in any order|
|9/2/2013 4:18:23||Jordi Boggiano||If you care about performance this makes sense, and that's the point of caches really.||Yes||Composer||Yes, as a required feature||save() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);||It's the most barebones and allows us to add helpers later if needed without shooting ourselves in the foot.|
|9/2/2013 10:03:30||Guilherme Blanco||Different drivers have completely diverging internal implementations.|
Some of them "lock" the entire collection of items being unable to load when you're either traversing the list of items (getItems when retrieving all items). Other drivers like Memcache just don't provide the API to retrieve all items.
That's why I think it'll be better as a separate interface, which would allow more specific control over getItems. I'd separate as BulkOperationCache which would support all Multi-XXX we desire
|Yes||Doctrine||Yes, as optional extra interfaces||save() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);||An items shouldn't know how to save itself. It violates SRP.|
As an addendum to that, save (which I think should be renamed to set) should also support a second parameter which is the configuration to set a new index. That is where we open the possibility for drivers such as Riak to support timeout, number of replicas writes before return operation was ok (aka. write quorum), If-Modified-Since, etc.
My general recommendation is taking a look at my alternate cache proposal which explains why we should have a separate API (such as why TTL should be at Cache Collection level). Link: https://groups.google.com/forum/#!msg/php-fig/ciByHJoufSI/_XIIn7bpz5kJ
|9/3/2013 9:25:46||Michael Cullum||If it's optional or available in some libs but not others then another lib doesn't have them in it's interface then you have problems taking one out and dropping in another.||No||phpBB||Yes, as a required feature||We should have a separate save() method from set(), so that all setters may be called in any order|
|9/3/2013 15:31:57||Josh Hall-Bachner||multi-* operations provide a valuable way to abstract certain operations that are likely to be frequently used and enforcing them as mandatory ensures that they will be available in all compliant libraries.||No||stash-bundle||Yes, as a required feature||save() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);||This is probably the most elegant of the available options. Save on the item strikes me as an incorrect encapsulation. I was originally in favor of the first option, but when I wrote out an example I realized it's not clear enough.|
|9/5/2013 22:05:05||Ryan McCue||No||SimplePie||It's fine as-is with just multiple-get support||The pool should be responsible for retrieving and storing all data, while the item itself should be for the actual item. If overriding the item, it doesn't make sense to override how it's saved, but it might make sense to override how it's stored (serialization/cleanup, e.g.).|
|9/6/2013 3:34:46||Frédéric G. MARAND||Caching is all about performance, and round-tripping to a cache server means more latency than needed if there is any way the backend can support it, so PSR-Cache should foster adoption of multiple operations by compliant backends.||No||Drupal||Yes, as a required feature||We should have a separate save() method from set(), so that all setters may be called in any order||If these other methods return the item, it allows for a compact style familiar in other environments, like $item->setTtl(60)->setTag('foo')->save();|
|9/6/2013 5:46:47||Lukas Kahwe Smith||Mostly because I do not want to delay things much further.||Yes||Jackalope||It's fine as-is with just multiple-get support||I prefer the CacheItem to be as stupid as possible.|
|9/6/2013 10:18:03||Phil Sturgeon||Multi-set gets bloody complicated, and letting the user get on with that in a loop seems just fine to me.||Yes||PyroCMS||It's fine as-is with just multiple-get support||You getItem from the pool, mess around with it using setters and getters, then commit it back to the pool with a save method. Consistent, extensible and logical.|
|9/6/2013 10:38:06||Chuck Burgess||In combination with having Pool::save()/commit() be responsible for writing to the backend all the Item level set() changes that are pending, I think the Pool::commit() itself solves the multiSet() use case, while allowing for multiGet() to remain available.||No||phpDocumentor||It's fine as-is with just multiple-get support||If Item::set() is going to be local only (object updated, not backend), then I think the Pool becomes responsible for committing changes, thus Pool::save() or even Pool::commit(). I'd lean towards commit() since the overall concept equates well to the database concept.|
Pool::commit()/save() might perhaps also solve the multiSet() question. Having many Items that have set() new values on themselves, then having the Pool do a commit(), is effectively a multiSet() in my mind.
|9/6/2013 11:06:18||Amy Stephen||Loops on the get, set, delete are fine, no reason to complicate||No||No, remove it entirely for now||We should have a separate save() method from set(), so that all setters may be called in any order||Would prefer a simplistic set approach and wait for tags, namespaces, etc. - but if that cannot be done, separate the set and save properly|
|9/6/2013 14:09:24||Robert Hafner||Complexity is the main reason for avoiding this for now. As it's been over 20 months that we've worked on this, I feel getting a simple version that people can use is vital.||No||Stash||No, remove it entirely for now||There's no problem here. The inconsistency and SRP violation is OK.||I disagree completely with the question, and think the last answer ("The inconsistency and SRP violation is OK") is misleading and will bias people away.|
You are never going to set a value and not save it. Having different ways to set things makes no sense to me.
|9/6/2013 22:53:24||Paavo-Einari Kaipila||Some kind of CacheItemCollection shipped with PSR-6 would be a good idea. The whole point of PHP-FIG is to reduce code in the world :) However, I find it hard to imagine any kind of multi-set/delete while still keeping api consistent.||No||It's fine as-is with just multiple-get support||There's no problem here. The inconsistency and SRP violation is OK.||Current set() is consistent with many existing caching systems (apc, wincache, redis, memcache etc.).|
|9/7/2013 17:23:24||Gaelan Steele||I don't see a use case for this.||No||Drupal||Yes, as optional extra interfaces||The pool handles saving. I think that is the most correct implementation in terms of Separation of Concerns.|