Justizin wrote:
This is incorrect. If we are storing generated values based on:
(context, view_name, method_name, keywords)
This is an entirely acceptable key for:
Zope2 RAMCacheManager
Zope3 RAMCache
MemcachedManager, which could be based on either of the above
Sure, but that doesn't mean we wouldn't get false positives in the cache
using this approach.
Keep in mind, esp with AJAX, that some requests to the same context
referring to similar data may hit different zope clients and/or
threads.
Yes. This doensn't solve that at all, nor does it attempt to. The cache
lives exactly as long as one request, and then disappears.
The keys are bound to the context and the perspective from which it is
being accessed, not the request, and there's no reason they should be
request-specific.
Yes there is. Almost all of these values are valid in a particular
request, but could be radically different in the next request.
It may be necessary to also use roles in the key, but in comparison
with a hash of the context and all arguments to a method, that's
probably minimal.
Roles, local roles, groups, the changing state of the portal (e.g. some
more content is added, removed etc), probably other things I can't think
of right now. The complexity is potentially unbounded, which means that
the user of the decorator will need a very deep understanding of how the
value is cached if they are to avoid false positives in the cache, which
in turn would likely lead to insane bugs (note, this is a lot different
from caching a piece of content or so, it could lead to SiteErrors all
over the place due to inconsistent state being recorded).
There is some concern that memcached may have a limit on cache key
sizes, but it's a very simple C app and could probably be extended
easily.
I have no interest in touching C code (or shipping Plone with custom C
code). Almost no-one in the community knows how to maintain it.
Feel free to prove me wrong, but not by modifying plone.memoize to
support this, it's expressly not its stated purpose.
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
