> As I understand what you said, PSR-16 represents a cache server, and flush() would wipe everything on there.
I find this answer highly problematic, because that means that there is *no* concept to support back-ends that can (efficiently or not) support multiple collections. > The reason IMO is that clearing the namespace is very inefficient as if the cache backend doesn't have a concept of namespacing you are forced to iterate over all keys, or keep track of all keys you write. That's not entirely correct. Whether or not a back-end supports multiple collections, and whether or not that affects performance, is completely dependent on the back-end. For example, a file-based cache is no faster or slower, and can support the concept of multiple collections easily, e.g. by simply mapping each instance to a different subfolder. The same is likely true for a lot of back-ends. The efficiency question depends entirely on the back-end and it's capabilities, configuration, etc. I think it's hugely problematic to say that this a cache-instance represents a server, because that leaves no room for a collection-concept, short of building some sort of collection-facility as a layer over a cache-instance - but that's hugely problematic, since, for example, in the case of a file-based cache, this *will* make it very inefficient, e.g. will *have* to store and enumerate keys, which will be much slower (and much less organized) than simply designating a dedicated root-folder at construction. Also, defining the abstraction as representing a server, means that, by definition, everyone *does* have to worry about key collisions, e.g. everyone must "namespace" everything, everywhere, always. It also means, as you mentioned, that you don't really expect consumer code to call clear() ... which means, in other words, that a (simple, efficient) means of clearing the cache isn't really effectively something this abstraction offers as a consumer-facing feature at all. I would very much like to see the abstraction defined as representing a cache-collection instead, because, as far as I can figure, there is no other way to have simple, efficient collection-support. A collection, in that case, *may* be an entire server, but that's going to depend on your use-case. Let's consider two real-world examples: a simple, file-based cache, which does have the capacity for multiple collections via multiple root-folders, and an APC back-end, which doesn't have built-in support for multiple collections on a single instance. In the case of a file-based cache, server-abstraction as the concept doesn't really make any sense, because there's no reason you would want multiple instances of a file-based cache to also (for example) clear() the contents of other instances - you also would not expect such a cache to have key-collisions. I have already implemented a file-based PSR-16 cache, and it's only natural to have a constructor that takes a $root_path, which naturally results in multi-collection semantics. If I had to implement it with server-semantics, I would need a constructor that takes something like a $file_store object as argument and delegates all operations to a "cache server", e.g. calling clear() would clear all instances of the file-store. That would be extremely unnatural and impractical. For an APC back-end, there would be numerous ways to implement that, and each would have different performance characteristics. For example, you could have a simple APC-based implementation, which writes to a dedicated APC instance. With server-based semantics, having multiple instances of such a cache doesn't make sense at all, since one instance would effectively clear() the contents of all other instances - in this case, what you should do, is have a *single* instance shared between all consumers, since that's effectively the functionality you'd get from having multiple instances anyway. In other words, it also naturally has collection-semantics, just that there's only one collection. (and there may well be use-cases for that, it's dependent on the needs of the project.) Another example would be an APC-based implementation that trades off some performance by doing collection-management, but allows for multiple collections on the same server. There are definitely use-cases for that, e.g. hosted projects on servers that only offer one APC instance to each client. Bottom line: I just don't think a server-abstraction as an isolated concept makes sense, because it implies that everyone should expect key-collisions, side-effects from calling clear(), and other practical problems. A collection-abstraction is much simpler to work with, and doesn't prevent you from implementing server-*based* collections - but the correct thing to do, in that case, is bootstrap your project to use the same collection-instance, *understanding* that key-collisions may occur, and that clear() will of course clear the entire collection, even if multiple consumers are using the same collection. Please do consider this very carefully. This is *not* just a matter of quibbling over words - it completely changes the meaning of the abstraction, the expectations for a consumer, implementation strategies, and so on. A server-abstraction *precludes* implementations that support multiple collections - a clear() method, by definition, would clear the contents of the *server*. Compare this with a collection-abstraction, where a clear() method, by definition, clears the contents of the *collection*. The latter does *not* prevent you from having a collection that happens to be a server. The former *does* prevent you from having a server that supports multiple collections, which just isn't the reality we have. On Sun, Nov 27, 2016 at 2:56 PM, Jordi Boggiano <j.boggi...@seld.be> wrote: > On 25/11/2016 11:21, Rasmus Schultz wrote: > >> Assuming I understand the concept correctly, I would *not* expect a >> cache-instance to flush the entire server, but rather to flush only the >> collection represented by the cache-instance. >> >> Doctrine's cache-abstraction includes the concept of "namespaces", which >> equate to collection IDs - but here the distinction is clear, since it >> includes two distinct methods for clearing a collection with deleteAll() >> vs clearing the entire server with flush(). >> >> With PSR-16, there is only method, flush(), so it's extremely important >> we understand what precisely the scope of a cache-instance is: a entire >> server, or a collection on a server? >> > > As I understand what you said, PSR-16 represents a cache server, and > flush() would wipe everything on there. The reason IMO is that clearing the > namespace is very inefficient as if the cache backend doesn't have a > concept of namespacing you are forced to iterate over all keys, or keep > track of all keys you write. > > I would generally not expect a library I give a Cache to to call flush(), > because that's kinda crazy for most things if you wanna do invalidation you > do it per item you don't blow the whole cache, or at least that should be > an application developer decision.. > > What I typically do is defining multiple cache instances using redis > databases for "namespacing", so that the keys can not possibly conflict, > and flushing one db doesn't impact any other db. That is maybe not possible > with Memcached, I have no idea. > > Cheers > > -- > Jordi Boggiano > @seldaek - http://seld.be > > -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit https://groups.google.com/d/to > pic/php-fig/kSj_yVbkwOw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/php-fig/aa6d9626-a60e-74dc-5712-421779f0c021%40seld.be. > > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_ieddcv0XVJ7ms-J25mvVdsQ6N97-Fg2%3DuL%2BHqwQbF2EQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
