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

[Sanne Grinovero]

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 at hibernate.org> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev