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

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(a)gmail.com&gt; 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(a)hibernate.org > > <mailto:steve@hibernate.org>> wrote: > > > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner <gbadner(a)redhat.com > > <mailto:gbadner@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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev