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

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(a)hibernate.org&gt; 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(a)hibernate.org&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev