|
|
|
|
|
|
This is meant to cover both implicit and explicit cases of downcasting. FWIW JPA only defines support for explicit downcasting; implicit downcasting is a HQL-only feature (check for strict jpql compliance). _Additionally, JPA only defines support for downcasting in the FROM and WHERE clause. So Hibernate's support for explicit downcasting in other clauses also needs a strict jpql compliance check._
This needs to keep more than "just" downcast target ; . Ultimately we also need to track where understand some context for the downcast occurred , as that later affects the SQL that needs to be generated ( . One example of that is the need to account for {{ includeSubclasses }} as we generate SQL in terms of which subclass joins to render, if any. Depending on how the filtering aspect of TREAT is handled (encoded into join, local predicate, etc ) we may need this information to understand whether to INNER join or OUTER join .
This also affects how AttributeReferenceExpression is modeled, and ultimately rendered. Currently AttributeReferenceExpression hold reference to the {{FromElement source}} it "originates from". IN the case of a TREAT that is currently a wrapper for the "treated from element". I'd like to get away from the wrappers, if possible. One option, rather that wrapping, is to register the "treated FromElement" into the alias registry under its implicit/explicit alias (for use in expressions) but to not render it into the tree.
Another option is to piggy-back on Hibernate's notion of implicit downcasting in terms of expressions originating from the treated FromElement. So we'd still register the "treat target" with the FromElement, but just ignore it in expressions using the treated FromElement. This has a big drawback in terms of TREATs that occur in predicates.
Yet another option is to change up the modeling of {{source}} on AttributeReferenceExpression to be some form of {{[FromElement, subclass-indicator]}} tuple where _subclass-indicator_ is some form of indication of the specific subclass the attribute reference comes from within that "abstract schema type" (to borrow the JPA phrase) which might be as simple as holding the concrete "entity type" reference, etc.
Anyway, still a lot to think through...
|
|
|
|
|
|
