6:41 a.m.
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?
7:06 a.m.
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 <steve(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:11 p.m.
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 <gunnar(a)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 <steve(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
3298
days inactive
3301
days old
2 comments
2 participants
participants (2)
-
Gunnar Morling -
Steve Ebersole