5:25 p.m.
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> wrote:
Yep, it was clear
On Tue, Apr 24, 2018 at 4:57 PM Gail Badner <gbadner(a)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>
> 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> 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> 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
>>
>>
>