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.