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 <gbad...@redhat.com > <mailto:gbad...@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 > <st...@hibernate.org <mailto:st...@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 <gbad...@redhat.com > <mailto:gbad...@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.bei...@gmail.com > <mailto:christian.bei...@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 > <st...@hibernate.org <mailto:st...@hibernate.org> > > > <mailto:st...@hibernate.org > <mailto:st...@hibernate.org>>> wrote: > > > > > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner > <gbad...@redhat.com <mailto:gbad...@redhat.com> > > > <mailto:gbad...@redhat.com > <mailto:gbad...@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@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > <mailto: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
