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 <st...@hibernate.org> wrote:
> Yep, it was clear
>
> On Tue, Apr 24, 2018 at 4:57 PM Gail Badner <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>
>> 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> 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> 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>> wrote:
>>>> > >
>>>> > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner <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
>>>> > 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
>>>
>>>
>>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
