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(a)redhat.com
<mailto:gbadner@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(a)hibernate.org <mailto:steve@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(a)redhat.com
<mailto:gbadner@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(a)gmail.com
<mailto:christian.beikov@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(a)hibernate.org <mailto:steve@hibernate.org>
> > <mailto:steve@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>
> > <mailto:gbadner@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
<mailto:hibernate-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev