[hibernate-dev] How to deal with a constant in CriteriaQuery
Christian Beikov
christian.beikov at gmail.com
Tue Apr 24 18:39:25 EDT 2018
That's a possibility indeed, but there will most likely always be some
nice function that uses a weird keyword syntax for which there is no
first class support.
So even if we propose this, IMO we should still also propose to add a
note to the function invocation syntax section, that a function may
resolve to a JPA vendor defined funciton as well. This would be like a
"last resort" to use a function at least in a "standard way". If the JPA
vendor doesn't define the desired function, it's up to the user to
making use of JPA vendor specific APIs for registering the function.
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 25.04.2018 um 00:25 schrieb Steve Ebersole:
> 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 <steve at hibernate.org
> <mailto:steve at hibernate.org>> wrote:
>
> 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