[hibernate-dev] How to deal with a constant in CriteriaQuery
Christian Beikov
christian.beikov at gmail.com
Tue Apr 24 18:20:50 EDT 2018
I don't like this either. It simply feels wrong as this is a "provider
specific" keyword i.e. some DBMS might not even support DATEDIFF. IMO
when we decide to abstract over the DBMS specifics by introducing a HQL
DATEDIFF or specifying a JPQL DATEDIFF, we could just as well introduce
separate functions which would ultimately look a lot cleaner.
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 25.04.2018 um 00:11 schrieb Steve Ebersole:
> Yep, it was clear
>
> On Tue, Apr 24, 2018 at 4:57 PM Gail Badner <gbadner at redhat.com
> <mailto:gbadner at 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 at hibernate.org <mailto:steve at 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 at redhat.com
> <mailto:gbadner at 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 at gmail.com
> <mailto:christian.beikov at 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 at hibernate.org <mailto:steve at hibernate.org>
> > > <mailto: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>
> > > <mailto: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.
> > >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> <mailto:hibernate-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
More information about the hibernate-dev
mailing list