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

[Steve Ebersole]

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.