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

[Gail Badner]

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> 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>> wrote:
> >
> >     On Tue, Apr 24, 2018 at 8:45 AM Gail Badner <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
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>