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 <st...@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 <and...@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 <st...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
