Closed abacaphiliac closed 7 years ago
Actually, this behaviour is completely compatible with PSR-6.
PSR-6 libraries don't need to provide interoperability between different pool & item objects. A pool should only be able to store the item object that it created itself, not one that was created from another pool (from another library)
This was a heated topic for that PSR. The reason there should not and can't be interoperability between pool & cache objects from other libraries is that there is no standard way to pass the expiration time from an item to a pool. There is no default public method for that, so every library has their own implementation to pass that bit of data along.
In addition, Scrapbook does a bunch of optimizations (e.g. pool won't actually request the data from the cache when the item is created, but when it's actually used - batch-loading all the other in-flight values at the same time) that most (all?) other libraries don't, further making it impossible to provide compatibility...
cool, thank you for the consideration and explanation. i wish i had followed that debate more thoroughly. some things are not as easily apparent until you get into the weeds haha. thanks again.
hi @matthiasmullie ,
thank you for this great package. i was able to use this to test the feasibility of switching Memcache with Couchbase in my application.
in an effort to slowly roll out this change to sets of users, i integrated cache/chain-adapter to dual-store some data in both pools for safe roll-out and roll-back.
unfortunately it appears that this package enforces the use of
\MatthiasMullie\Scrapbook\Psr6\Item
instead of\Psr\Cache\CacheItemInterface
in\MatthiasMullie\Scrapbook\Psr6\Pool::save
and\MatthiasMullie\Scrapbook\Psr6\Pool::saveDeferred
, which means this solution is not truly interoperable with other PSR-compatible cache solutions, at least not in a Chain.is there any plan to depend exclusively on the PSR interface(s) instead of concretes?