Re: [hibernate-dev] HHH-12146 - subclass-specific caching

Its not any different than `#get( LegalEntity.class, key )` in the old config when key refers to a Person and Person is *not* in the cache simply because it has not been loaded/saved via this SF. On Tue, Dec 12, 2017 at 12:33 PM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > Conceptually it sounds useful but I'm wondering about this being safe > to do in various more tricky mapping scenarios. > > For example consider this case: > > @Inheritance(...) > @Cache(...) > @Cacheable(true) > class LegalEntity { > ... > } > > @Cacheable(false) > class Person extends LegalEntity { > ... > } > > @Cacheable(true) > class Company extends LegalEntity { > ... > } > > [N.B. the parent class is no longer abstract] > > Now imagine we have to implement a polymorphic load: `load(key, > LegalEntity.class)` > > Would you be able to use the 2LC safely in all possible inheritance > mappings? > > I'm particularly curious about the possibility of a Person being > stored, but since we won't have data about the Person in the cache > we'd materialize the load as a LegalEntity. > > Incidentally while writing this example I realize that such a mapping > could trigger issues even with existing caching options. > > Thanks, > Sanne > > > > On 12 December 2017 at 14:49, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > HHH-12146 is about being able to enable/disable caching at various > levels > > in an entity hierarchy. E.g., given a hierarchy such as `Person` and > > `Company` both extending `LegalEntity`, this would allow users to say > that > > only `Company` should be cached but not `Person` nor any other > > `LegalEntity` subclass. > > > > The underlying approach here is to still define region and > access-strategy > > information per-hierarchy - users will simply be able to opt out of (or > > into) caching particular subclasses. In my initial attempt I simply > > allowed both `@Cache` and `@Cacheable` to appear anywhere in the > > hierarchy. However, allowing `@Cache` (as currently defined) implies > that > > users should be able to define different regions and/or access > strategies > > for various subclasses within the hierarchy. Stepping back, I thought a > > better solution would be to continue to support `@Cache` only at the > root > > level and define this new feature in terms of `@Cacheable` at the > various > > levels. This has a few implications that I wanted to discuss. > > > > The main thing is that this means that applications using just `@Cache` > to > > define caching would still only be able to declare caching for the > entire > > hierarchy. But I think that is ok because that was the legacy behavior, > > and so nothing is really changing there. If we find `@Cache` on the > root > > we'd assume an implicit `@Cacheable(true)`. I think some examples will > > help explain... > > > > > > Current behavior > > > > @Inheritance(...) > > @Cache(...) > > abstract class LegalEntity { > > ... > > } > > > > class Person extends LegalEntity { > > ... > > } > > > > class Company extends LegalEntity { > > ... > > } > > > > In the current behavior both `@Cache` and `@Cacheable` are only valid > on > > the root as seen above. Placing them on any subclass results in an > error. > > Note too that we could have used `@Cacheable` here instead of `@Cache` > in > > which case the default `@Cache` values would be applied. It was also > legal > > to use both together. In fact, a portable application would use > > `@Cacheable` with or without `@Cache`. > > > > > > Proposed behavior > > > > @Inheritance(...) > > @Cache(...) > > @Cacheable(false) > > abstract class LegalEntity { > > ... > > } > > > > class Person extends LegalEntity { > > ... > > } > > > > @Cacheable(true) > > class Company extends LegalEntity { > > ... > > } > > > > Here we have the root disabling caching (assuming > > `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that setting. > > `Company` however overrides that to enable caching. We still have > > `@Cache` attached to the root to define the specifics of caching > (region, > > access strategy). But as noted earlier, we could have left off `@Cache` > > and accepted the defaults. > > > > I also propose that we continue to accept `@Cache` (without explicit > > `@Cacheable`) as implying `@Cacheable(true)` although `SharedCacheMode` > > plays a part in that too. > > > > Anyway, I wanted to make sure everyone agrees with this. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >