[hibernate-dev] How to deal with a constant in CriteriaQuery

[Christian Beikov]

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 at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     On Tue, Apr 24, 2018 at 8:45 AM Gail Badner <gbadner at redhat.com
>     <mailto:gbadner at 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.
>