5:39 p.m.
That's a possibility indeed, but there will most likely always be some
nice function that uses a weird keyword syntax for which there is no
first class support.
So even if we propose this, IMO we should still also propose to add a
note to the function invocation syntax section, that a function may
resolve to a JPA vendor defined funciton as well. This would be like a
"last resort" to use a function at least in a "standard way". If the
JPA
vendor doesn't define the desired function, it's up to the user to
making use of JPA vendor specific APIs for registering the function.
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 25.04.2018 um 00:25 schrieb Steve Ebersole:
What I was proposing instead was to treat extract and hopefully
datediff as first-class citizens:
cb.extract( DateField.DAY, startDate ).as( Integer.class );
cb.extract( DateField.DAY, endDate - startDate ).as( Integer.class );
cb.datediff( DateField.DAY, endDate, startDate ).as( Integer.class );
s.createQuery( "... where extract( DAY, startDate ) ..." );
s.createQuery( "... where extract( DAY, endDate - startDate ) ..." );
s.createQuery( "... where datediff( DAY, endDate, startDate ) ..." );
On Tue, Apr 24, 2018 at 5:11 PM Steve Ebersole <steve(a)hibernate.org
<mailto:steve@hibernate.org>> wrote:
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