[hibernate-dev] How to deal with a constant in CriteriaQuery

Christian Beikov christian.beikov at gmail.com
Tue Apr 24 18:20:50 EDT 2018


I don't like this either. It simply feels wrong as this is a "provider 
specific" keyword i.e. some DBMS might not even support DATEDIFF. IMO 
when we decide to abstract over the DBMS specifics by introducing a HQL 
DATEDIFF or specifying a JPQL DATEDIFF, we could just as well introduce 
separate functions which would ultimately look a lot cleaner.


Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 25.04.2018 um 00:11 schrieb Steve Ebersole:
> Yep, it was clear
>
> On Tue, Apr 24, 2018 at 4:57 PM Gail Badner <gbadner at redhat.com 
> <mailto:gbadner at redhat.com>> wrote:
>
>     I just want to make sure that what I'm suggesting is clear.
>
>     datediff would be registered as a function:
>
>     registerFunction("datediff",
>         new StandardSQLFunction("datediff", StandardBasicTypes.INTEGER )
>     );
>
>     Then, to specify datediff with the keyword, day, as the first
>     parameter (rendered without quotes):
>
>     final Expression<Integer> diff = cb.function("DATEDIFF",
>     Integer.class, cb.keyword("day"), ... ).as(Integer.class);
>
>
>     On Tue, Apr 24, 2018 at 1:43 PM, Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>
>         I'd personally not like that approach.  I think specific
>         registrations (for extract and datediff) are better options
>
>
>         On Tue, Apr 24, 2018, 1:18 PM Gail Badner <gbadner at redhat.com
>         <mailto:gbadner at redhat.com>> wrote:
>
>             When I asked about whether JPA should support this in the
>             future, I was
>             thinking along the lines of adding something like the
>             following
>             to javax.persistence.criteria.CriteriaBuilder:
>
>             Keyword keyword(String value);  // rendered as a String
>             without quotes
>
>             or:
>
>             Expression<String> literal(String value, encloseInQuotes);
>
>
>             On Tue, Apr 24, 2018 at 7:56 AM, Christian Beikov <
>             christian.beikov at gmail.com
>             <mailto:christian.beikov at gmail.com>> wrote:
>
>             > Maybe we should wait until it transitioned to Eclipse
>             then? Or do you
>             > think it might make sense to start discussions already?
>             >
>             > The API could be String based by default but allow to
>             "unwrap" to do
>             > something provider specific. If the providers model
>             requires it, the
>             > String could be parsed by the provider.
>             >
>             > Imagine an API like the following
>             >
>             > interface SQLFunction {
>             >    ExpressionType getType(FunctionContext ctx,
>             List<ExpressionType>
>             > argumentTypes);
>             >    Expression render(FunctionContext ctx,
>             List<Expression> arguments);
>             >
>             >    interface FunctionContext {
>             >      ExpressionType getExpressionType(Class<?> javaType);
>             >      Expression getExpression(String expressionString);
>             >      <T> T unwrap(Class<T> clz);
>             >    }
>             >
>             >    interface ExpressionType {
>             >      Class<?> getJavaType();
>             >      <T> T unwrap(Class<T> clz);
>             >    }
>             >
>             >    interface Expression {
>             >      String getExpressionString();
>             >      <T> T unwrap(Class<T> clz);
>             >    }
>             > }
>             >
>             > That's just a rough idea of how it could look.
>             >
>             > Mit freundlichen Grüßen,
>             >
>             ------------------------------------------------------------------------
>             > *Christian Beikov*
>             > Am 24.04.2018 um 16:33 schrieb Steve Ebersole:
>             > > JPA is technically under the old JCP still AFAIK. So
>             for now the
>             > > process would be the same it has always been.
>             > >
>             > > I just do not see how this would ever get agreed upon
>             for a
>             > > standardized contract - it is so very dependent upon
>             how the provider
>             > > models the query (SQM e.g.) versus the specific
>             mechanism they use to
>             > > render it (SQL AST).
>             > >
>             > >
>             > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole
>             <steve at hibernate.org <mailto:steve at hibernate.org>
>             > > <mailto:steve at hibernate.org
>             <mailto:steve at hibernate.org>>> wrote:
>             > >
>             > >     On Tue, Apr 24, 2018 at 8:45 AM Gail Badner
>             <gbadner at redhat.com <mailto:gbadner at redhat.com>
>             > >     <mailto:gbadner at redhat.com
>             <mailto:gbadner at redhat.com>>> wrote:
>             > >
>             > >         Yes, that should work with CriteriaQuery as
>             well. It's a
>             > >         reasonable
>             > >         workaround.
>             > >
>             > >         If JPA doesn't support this now, is it
>             something that should
>             > >         be supported
>             > >         in the future?
>             > >
>             > >
>             > >     The problem with defining support for this in the
>             spec is that it
>             > >     is relying on Hibernate's "SQL function registry"
>             and its
>             > >     `SQLFunction` contract.  I seriously doubt we'd
>             get all the EG
>             > >     members to agree to some standardization of
>             anything like a
>             > >     `SQLFunction` contract.
>             > >
>             > >     I think proposing to add additional functions to
>             the spec as
>             > >     "built-in" is probably more likely.  I can
>             especially see EXTRACT
>             > >     being likely.  Maybe DATEDIFF. Oracle for sure
>             does not support
>             > >     DATEDIFF, but it does support the
>             EXTRACT-from-INTERVAL approach.
>             > >      Anyone know offhand other databases which to not
>             define DATEIDFF?
>             > >
>             > >     I personally think having DATEDIFF defined as
>             "built-in" is the
>             > >     best option as the provider can always map that to
>             > >     EXTRACT-from-INTERVAL for Oracle, etal - its much
>             harder to do
>             > >     that by mapping EXTRACT-from-INTERVAL to DATEDIFF.
>             > >
>             >
>             > _______________________________________________
>             > hibernate-dev mailing list
>             > hibernate-dev at lists.jboss.org
>             <mailto:hibernate-dev at lists.jboss.org>
>             > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>             >
>             _______________________________________________
>             hibernate-dev mailing list
>             hibernate-dev at lists.jboss.org
>             <mailto:hibernate-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>



More information about the hibernate-dev mailing list