I mean that the JPA contracts in general do not expose enough information to interpret them. Take the one example I mentioned in my email... Predicate. The JPA contracts do not give enough information to know if a Predicate is a BETWEEN, or a LIKE or a IS_NULL or ... they are all just Predicate. So SQM needs something else.
So I think we need to qualify the term visitor. The visitor pattern is a very specific thing. Visitation, as in the pattern, is defined in terms of the "visitable" (the Criteria nodes, here) and the "visitor" (the thing that does walking and is passed into the visitable). So that was the "first approach". We'd have CriteriaVisitor (the visitor). Each Predicate, Expression, etc would be a "visitable". We'd have a PredicateImplementor that accepts the CriteriaVisitor and returns an SQM Predicate. We'd have an ExpressionImplementor that accepts the CriteriaVisitor and returns the SQM Expression. Typical vistor pattern. What you are describing is just a walker. And yes, that is one of the options I laid out: the "second approach". So here we'd classify each Predicate, Expression, etc possibility as a specific SQM "criteria extension" type. So rather than just a "generic" PredicateImplementor with an accept(CriteriaVisitor) method we'd classify all of the understood predicate types with an SQM interface that ORM would need to use in its criteria impls. So, e.g. in SQM we'd have a org.hibernate.query.parser.criteria.BetweenPredicateImplementor that exposes the information we need to interpret that in SQM (testExpression, lowerBound, upperBound, isNegated). In ORM, org.hibernate.jpa.criteria.predicate.BetweenPredicate would need to implement that contract. And so on. On Mon, Nov 2, 2015 at 12:44 PM Gunnar Morling <gun...@hibernate.org> wrote: > Hi, > > What exactly DYM by "The criteria nodes would be expected to implement > an SQM extension accepting a visitor"? > > My first thought would have been a combination of the two approaches: > Let the criteria objects expose all the required data, make them > traversable by means of a visitor and have an SQM-specific visitor > implementation which converts each criteria object into its SQM > counter-part. > > --Gunnar > > > > > 2015-10-30 12:41 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > > I started work on SQM-24 which covers translation of criteria queries > into > > SQM. > > > > The difficulty with this is that the JPA contracts alone do not give > enough > > information to really be able to understand the semantics of the query; > > there is just not enough information exposed. I can get into specific > > examples if that helps, but for now lets take that as a given... > > > > So then how do we go about translating a criteria into an SQM? There are > > going to be 2 main approaches. Each requires some level of extension to > > the standard contracts: > > > > The first approach is to use visitation. The criteria nodes would be > > expected to implement an SQM extension accepting a visitor and do the > right > > thing. The gains here are the normal gains with the visitor pattern. > The > > downside is that this makes SQM highly dependent on the criteria impl > doing > > the right thing and makes the criteria impl sensitive to SQM (depending n > > how we expose the visitation methods to a degree). > > > > The second approach would be to extended the standard criteria contracts > to > > more fully cover the semantic. As one example, JPA defines just > Predicate > > (for the most part) without exposing the type of predicate. Is it a LIKE > > expression? A BETWEEN? A Comparison (=, !=, <, etc)? We just don't > know > > from the standard contracts. So we'd have to develop a full semantic > > extension model here. `interface LikePredicate extends Predicate`, > > `BetweenPredicate extends Predicate`, etc. > > > > I lean towards the visitor approach given these choices. Anyone else > have > > opinions? Other options? > > _______________________________________________ > > 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
