But yeah, API-wise it should be transparent to the users and in case we go with 1 (or warn instead of throw), even migration from OSCache will be transparent.
On Jul 28, 2011, at 9:51 AM, Andrus Adamchik wrote: > End users will need to understand (a) when planning their cache group use. > > (b) is explicitly allowed by Cayenne SelectQuery (and other queries) API. > Also this can happen implicitly when 2 queries with different cache groups > resolve to the same key. We have some options here: > > 1. Quietly ignore the possibility of multiple cache groups. In explicit case > use the first group, don't try to analyze the implicit case. > 2. Throw (or warn via the logs) on multiple cache groups per key. In explicit > case it will be easy to detect, in implicit case it will require a scan of N > caches (where N is the number of cache groups in the system). > 3. Throw (or warn via the logs) on multiple explicit cache groups per key. > Ignore implicit ones. > > Andrus > > > On Jul 28, 2011, at 9:37 AM, Christian Grobmeier wrote: >> Thanks for your explaination >> >>> (a) require more discipline from the users in assigning cache groups and >>> (b) disallow multiple cache groups per key (be it for the same query >>> instance or for different, but equivalent query instances). >> >> But surely this is something the enduser aka Cayenne-user will not >> have to deal with it right? >> In my imagination I choose "EHCache" from the modeler and Cayenne is >> doing everything for me. >> >> >>> >>> >>> On Jul 28, 2011, at 12:01 AM, Andrus Adamchik wrote: >>>> On Jul 27, 2011, at 11:39 PM, Christian Grobmeier wrote: >>>> >>>>> What is the difference to Cache-Groups then? >>>> >>>> (Also see my other email on this) >>>> >>>> The difference is subtle, but may be essential in some scenarios. OSCache >>>> cache groups are "tags" that can be applied to any combinations of cache >>>> keys (including multiple groups per key). E.g. on a certain event you may >>>> invalidate group1, and on some other event - group2, and these two groups >>>> may span over overlapping (but not equivalent) sets of keys. >>>> >>>> Using EhCache instances to emulate cache groups implies a hierarchy. All >>>> keys belong to either zero or one cache group. Now the user must ensure >>>> that 2 queries with the same cache key, but created in different places of >>>> the code are using the same group. >>>> >>>> This is not the end of the world of course, and I must admit that most >>>> often than not queries are actually organized this way already. >>>> >>>> Andrus >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> -- >> http://www.grobmeier.de >> > >
