[hibernate-dev] SQM - encoding type info into the tree
steve at hibernate.org
Thu Oct 6 13:19:34 EDT 2016
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...
> from Person p where p.active = ?1
> 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
> 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
More information about the hibernate-dev