[hibernate-dev] SQM - encoding type info into the tree

[Steve Ebersole]

To follow up, there is now a proposal[1] and a prototype[2] (on the ORM
side) for this.  It essentially follows option (1).

Davide is evaluating this atm for appropriateness for OGM.



[1]
https://github.com/hibernate/hibernate-semantic-query/tree/master/src/main/java/org/hibernate/sqm/domain
[2]
https://github.com/sebersole/hibernate-orm-sqm-poc/blob/master/src/main/java/org/hibernate/persister/common/internal/DomainMetamodelImpl.java

On Thu, Oct 6, 2016 at 12:19 PM Steve Ebersole <steve at hibernate.org> wrote:

> Well there is then the ideological argument about this being a *semantic*
> query tree.  I'd argue that resolving non-explicit types is part of that
> process.  But if the semantic interpretation does not understand that more
> contextual type system, then there is not really much to do.
>
> I don't think we lose anything.  We'd just do it later.
>
>
>
> On Thu, Oct 6, 2016 at 9:41 AM andrea boriero <andrea at hibernate.org>
> wrote:
>
> I'm inclined towards the second option but not sure if it can have
> limitations compared to the first one.
>
> On 5 October 2016 at 22:59, Steve Ebersole <steve at hibernate.org> wrote:
>
> In SQM's domain metamodel we decided to follow JPA's guidelines in terms
> of javax.persistence.metamodel.Metamodel.  That is to say... a Type in SQM
> describes a Java type not its database mapping, just as it is in JPA.
>
> As a concrete example of the difference and its implication, consider a
> Boolean attribute.  The Type for that attribute would be
> a BasicType<Boolean> which only describes the Java Boolean type; it
> contains no information about how that value is mapped to the database (aka
> it is not a "mapping type").  But this mapping information is important.
> It is simply not enough to know that the value is a Boolean, we have to
> know that it is "a Boolean mapped to a BIT" or "a Boolean mapped to a
> CHAR(1)" etc.
>
> As we are building the SQM, we ask the "consumer" (ORM, etc) to resolve
> domain metamodel info for us.  The ideal being that as as we build the SQM
> tree in SQM we could encode "mapping type" information from the consumer
> into the tree structure.  But the problem is how to define access to a
> "mapped type system" when SQM's type system is strictly domain-based.
>
> Where this really becomes problematic is when determining the "implicit
> type" for Expression nodes in the tree.  Consider an example...
>
> {code}
>     from Person p where p.active = ?1
> {code}
>
> The idea is that we really want to be able to infer the type of the "?1"
> parameter expression based on its context in the query.  Since it is used
> as an operand of a equality predicate we know that its type should be the
> same as the other operand, here: "p.active".
>
> But this is where the domain-type/mapping-type split comes into play.  At
> the SQM level we have no notion of a "mapping type", so the fact that
> "p.active" is "a Boolean mapped to a BIT" or "a Boolean mapped to a
> CHAR(1)", which is really the information we want associated with the param
> expression.  All we can know from the SQM side is that "p.active" is a
> BasicType<Boolean> and therefore "?1" should be to - but that is not enough
> contextual info to handle binding that param properly.
>
> I see a few options to address this:
>
>    1. Add a notion of "mapping type" to SQM's domain metamodel.  The
>
>
>    "mapping type" would not be ORM-specific (aka, no expectation of JDBC).
>    Think of it more as a momento (pattern).  This effectively creates a
>    complete parallel of ORM's type system though, which always feels like a
>    code smell to me.
>
>    2. Simply leave determination of an expression's "implicit type" out of
>
>
>    SQM.  Resolving an expression's implicit type based on Type as defined
> by
>    JPA and currently by SQM is simply not expressive enough to be of any
>    value.  As the SQM consumer processes the SQM tree it would make that
>    determination then.
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>