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
