I'll take a look at TYPO3 Flow for sure, thanks for pointing it out.Can you describe the uses cases and how you reached to the need of those features so we could have a overview/starting point for talking about them?Unfortunately I haven't used TYPO3 Flow nor did I had a need for those features until now, with locking being an exception, so my research might not reflect actual practice.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/vmwXgb2F3iMJ.
Yes, all children must be retrieved.We could have a depth parameter instead that controls the level of nesting before we stop retrieving objects BUT like I've said in the GitHub PR, supporting this would cause a large headache for storing engines that don't provide/can't emulate this easily, I'm thinking right now on Memcached/Redis/APC mainly. You could sort of do it in MongoDB/other NoSQL solutions or with files but I'm not aware of such a solution currently.
[ To get this going I would like to suggest that we discuss the common Interface first (PR #63), and discuss the followup extended interfaces (PR #not-yet): namespaces, tagging & depth later (in another thread). ]
First, thanks for restarting this cache discussion, much appreciated!Some comments on PR #63:
- I don't quite see the need for both a CacheItem & the &$exists param, the Item can either have a isValid() method, or get() can return null if there is no value (aka no cache item). Both alternatives would make sure BatchDriverInterface->getMultiple() gets this exists capability as well.
- A good step in right direction on removing constructors from the interfaces, but as mentioned in the PR I would even remove setCacheDriver(DriverInterface $cacheDriver); as a proxy implementation might take several drivers in it's constructor and allow for built in support for cache hierarchies, avoiding user code to have to deal with this like in the PR description example and the options example by @schmittjoh.
- hasSerializationSupport() is defined on both DriverInterface and BatchDriverInterface.
- Is hasSerializationSupport() need in the first place? We could also require that drivers need to handle this transparently, making them choose the best serializer available for the driver and making setSerializer() and related user code logic for this unneeded.
- I might have misunderstood but it should be documented that ItemInterface is a value/naked object, and no backend calls will be executed on it's set* & get* methods. If this is true, Item could be a class with properties instead of interface with methods, enforcing no logic.
- Is DriverInterface->set() $lifeTime a ttl? or a timestamp?
- Do we need the metadata functions on the basic / common cache interfaces? What is the use case and how is it supposed to be stored by the driver? (ignore last question if assumptions in 8 are correct)
- * I might have misunderstood something else as well, but it seems like the proxy will always have to store a hash value with the 'value', '_ttl' and '__expires' keys in addition to other meta data to be able to populate the CacheItem, if this is the case then &$exists can effectively be removed from DriverInterface->get() as false is not a valid value for CacheProxies.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/QHPxiZxKV94J.
I for one clearly don't want to help creating a standard which will then be considered by everyone as sucky as it might affect in my career path.
So if this is nonsense, prove why and how another approach, yours or the one from evert is better, with arguments or a pro/con list and help creating a better world ;)
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/f50MlRF7YVIJ.
Thanks for posting this here André.Please see my comments below:
On Friday, January 4, 2013 11:18:17 PM UTC+2, André R. wrote:[ To get this going I would like to suggest that we discuss the common Interface first (PR #63), and discuss the followup extended interfaces (PR #not-yet): namespaces, tagging & depth later (in another thread). ]That's the reason I've split the interfaces into two proposals but kept them in a single branch.While there's a need for those 'advanced' features, there's really not much support for them, safe for maybe locking which can be done relatively easily in any system that I can think of.If people are ok with having this topic split then more on the 'advanced' features could be discussed when the time for them will come.
First, thanks for restarting this cache discussion, much appreciated!Some comments on PR #63:
- I don't quite see the need for both a CacheItem & the &$exists param, the Item can either have a isValid() method, or get() can return null if there is no value (aka no cache item). Both alternatives would make sure BatchDriverInterface->getMultiple() gets this exists capability as well.
The reason for this is to make it more APC::fetch look-alike. On the other hand NULL would indeed make sense as it allows further features, see below, so I'll change this.
- A good step in right direction on removing constructors from the interfaces, but as mentioned in the PR I would even remove setCacheDriver(DriverInterface $cacheDriver); as a proxy implementation might take several drivers in it's constructor and allow for built in support for cache hierarchies, avoiding user code to have to deal with this like in the PR description example and the options example by @schmittjoh.
I wanted to have a feedback from at least one more person in regards to this.
We could have the method changed to:addCacheDriver(DriverInterface $cacheDriver, $priority = 100, $overwriteExisting = false);
In this case $priority could be just about any integer as there's no need add limits. We'll just need to specify that the value is extracted in the highest priority order.Since I'm not sure what happens when you want to add another driver with the same priority an existing one I've added the $overwriteExisting for it in the signature but I think that we should discard it and use overwrite as default procedure. Any thoughts on this?
- hasSerializationSupport() is defined on both DriverInterface and BatchDriverInterface.
Thanks! Copy paste isn't that good sometimes :)
- Is hasSerializationSupport() need in the first place? We could also require that drivers need to handle this transparently, making them choose the best serializer available for the driver and making setSerializer() and related user code logic for this unneeded.
The reason for it is so that you can inject your serializer if you want to, making the drivers more compatible with each-other across implementations. It indeed brings some problems and more code to user-land. We can drop it altogether if there's no need for it. It's always easier to delete rather that add.
- I might have misunderstood but it should be documented that ItemInterface is a value/naked object, and no backend calls will be executed on it's set* & get* methods. If this is true, Item could be a class with properties instead of interface with methods, enforcing no logic.
You got it right, there shouldn't be any logic in the Item in regards to backend calls BUT, for example, you could chose to provide more metadata functionality, like having a method called increaseRefreshCount() so that you can control the number of times the object was refreshed in the main priority cache backend before you perform logic on it, like a full refresh of the item in all cache backends.
It would indeed be possible to have this with a class by extending it but I'm not sure how FIG should provide code like this. There's some discussion in the other threads about this topic so maybe a by-law should be considered to have a clear direction for this.
- Is DriverInterface->set() $lifeTime a ttl? or a timestamp?
Most common case is a TTL in seconds so but I'll need to add this to the specs. The Item should store the timestamp of the save moment as well in order to have a way to compute the expiration time.
- Do we need the metadata functions on the basic / common cache interfaces? What is the use case and how is it supposed to be stored by the driver? (ignore last question if assumptions in 8 are correct)
I'm not sure there's a need for metadata in the existing systems for simple use cases. It was added with the purpose of expansion, see the Extended version.
- * I might have misunderstood something else as well, but it seems like the proxy will always have to store a hash value with the 'value', '_ttl' and '__expires' keys in addition to other meta data to be able to populate the CacheItem, if this is the case then &$exists can effectively be removed from DriverInterface->get() as false is not a valid value for CacheProxies.
Then way I see this working is just dumping the CacheItem object in the cache driver (APC/Memcached/DB via serialize()) directly. You can see demo implementation of how I'd see this done. As for &$exists I've covered it above.
Best regards,Florin
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/OzQz3lhq_TIJ.
Hi Andre,The purpose of this initial cache PSR is to release a very simple and working cache class with the most basic but functional methods, i.e: exists/get/set/remove.The fancy things you're asking about such as pooling and hierarchical stacks should come at a later PSR.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/UTNu50Th_MQJ.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/6g4o3KQAZTkJ.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/tC0n6hXytDMJ.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/yzn7GMeT56MJ.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/OPgPtjmKFs8J.
Since 'exists' and the likes seem to be rather a point that many don't agree with, I'll remove it from the proposal. Its use case would be to check if a key exists in the cache without retrieving it but since this would fall into a rather narrow use case, I think it's better to remove it indeed.
I've removed 'CacheItemInterface::setTtl and CacheItemInterface::getRemainingTtl' from this proposal only to have them in the extended version, the one where some of the other functionalities are described. The reason I've did so is that not all people would need it and it would make storing the items less space consuming. If more people would think about adding this back then I see no reason why we can't have it here, aside from the increased space requirements for storing the items.
'CacheInterface::setDefaultTtl' while it is a configuration function I believe that since we specify the existence of such a functionality, having a function present in the common interface for enabling that functionality should be there as well. If others agree, I'll remove it as well, or if you can point me out some more documentation to better learn about how to treat these things then it will be great :)
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/hEuk8rcKi90J.
Unfortunately I'm not very sure what to understand from your e-mail, reallysorry about that, but if I read it right, then you suggest to add a separateinterface for TTL aware storages.
That would totally be fine with me, I do understand why you want to haveit separated. I think it would be nice if you can provide a concrete exampleof a storage that is not TTL aware or a case when this is not needed/usedand that would suffer from lacking this feature. You can send a PR to myrepo and have the changes for the interfaces done + the example I'vementioned and we'll continue from there. Does it sound good for you?
CacheInterface::setDefaultTtlI do not think setDfaultTtl belongs on the interface. This is a configuration level thing. This was discussed at great length. Giving consumers of CacheInterface the idea that they should be able to alter the default TTL for the entire application is something that should not be allowed. It will get abused and people will not be happy about it.CacheItemInterface::setTtl and CacheItemInterface::getRemainingTtlWhy were these removed from the proposal? If we have setValue() we should probably have both of these. CacheItemInterface either needs to be a value object or it needs to be mutable and encapsulate all of the things that setValue defines as what is getting cached (essentially $value and $ttl).TTLI think I've heard Evert say a number of times that the [Spring cache interface][2] is a really good starting point. It doesn't deal with "exists" or "ttl" or anything like that, so we're already going above and beyond that. I'd argue that doing something really close to this interface for the first cache PSR would go a long way toward standardizing on cache.
As for the TTL. This is a open question as well.The model I have in mind is that when you want to save something to cache you will also know what's the time out for that item.
When you want to save three different items and you don't specify the TTL when you save the item then you'll need to have three different instances of the adapter that use the same connection only to have different timeouts in those instances or the same instance which just bounces the intervals back and forth. Or maybe I'm missing something. There was the proposal above with having the TTL specified with the save function in a interface called TtlAware or similar, I think that it would that be a better approach in this case, what do you think?
I've updated the interface again to the latest proposals. As always, any comments are welcomed.
Is that right?Thanks in advance.Regards,Andrew Eddie
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/R_yIrCl6ZFUJ.
Hello,Sorry for the mistake, copy-paste needs more love :d
Also, I've updated the proposal to better describe the role of the CacheItem.The mixed value is specified there in order to reflect that it can accept any type of user values, not just a restricted set of value types.One does not need to use a CacheItem in order to send it to the storage as it will introduce unnecessary complexity. Every time you need to store something you already know the key, the value and, maybe, the TTL for the item so there's no need to create a object, pass it to the driver which will the get the value from the object and store it.I hope this answers the questions. Let me know if I should detail further on this.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/7PJ8seVdkXIJ.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/ZL1OXemwlYcJ.
/** * This allows to clear (flush) all the cache contents * * return Boolean */ public function flush();
/** * This allows to clear all the cache contents * * return Boolean */ public function clear();
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/BMxhMpF3JMAJ.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/zuwfdKT7QEwJ.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/zuwfdKT7QEwJ.
I'd like 3) more that 2) as it allows for further extension.
Also, I've checked before submitting the change, the syntax is valid in PHP and I think I was against PHP 5.4/E_ALL (which includes E_STRICT iirc).But besides this, I do believe that 3) is the better one so if Paul as the others are ok with this as well, I'll change the interfaces one more time by Friday or a Thursday.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/swbctxAMN80J.
Usage: $cache->set($key, $val, array('ttl' => 86400));Constants Usage: $cache->set($key, $val, array(Cache::OPTION_TTL => 86400));
Say we later define a tagable interface or a namespace interface which allows for setting any of those.Having separate methods is not that great so that's why I think having a method that allows an options array is good.What do you think?
Regards,FlorinOn Wednesday, February 27, 2013 11:45:03 AM UTC+2, Andrew Eddie wrote:
On 27 February 2013 09:47, Paul Dragoonis <drag...@gmail.com> wrote:
Usage: $cache->set($key, $val, array('ttl' => 86400));Constants Usage: $cache->set($key, $val, array(Cache::OPTION_TTL => 86400));What other options do you want to allow for when setting a value in the cache?Regards,Andrew Eddie
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/W7aa7g1W1K4J.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/OEuruHeNKPcJ.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/OEuruHeNKPcJ.
I've been thinking a bit, and actually saw this one in reality:D, and you are right on this.Enforcing that only certain keys must be passed would be next to impossible as PHP folks tend to
The other option would be 2) and to have the next PSR accept only a Item in the save() function so that all the needed information is on the item itself.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/DreP3r0iJzgJ.
My vote from the beginning is set($key, $val, $ttl = null).. I've already laid out why this is good for libraries that do and don't support expiration.
Please review the proposal as well. I've updated to include the last feedback and I plan not to change anything in it, from functional point of view unless I've missed something critical in it.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
In an attempt to unify the proposals as well as some information from real life scenarios,I've created the following proposal for caching interfaces:Please review it and help me improve it so that at some point we could vote on this matterand give the community a direction for this matter.Thank you for your time and support!Best regards.