+1
In a time of IDE-support, whether it's Eclipse, NetBeans or IntelliJ, too
much abbrevation sounds no longer reasonable.
FUNCTION is more self-descriptive.
Werner
----- Original Message -----
From: "Adam Bien" <abien_at_adam-bien.com>
To: <linda.demichiel_at_oracle.com>
Cc: <jsr338-experts_at_jpa-spec.java.net>
Sent: Thursday, March 10, 2011 2:57 AM
Subject: [jsr338-experts] Re: JPQL function invocation
I would call it like the method: FUNCTION instead of FUNC
On 09.03.2011, at 19:54, Linda DeMichiel wrote:
> I haven't gotten any responses to this.
>
> Should I interpret silence as consent and add this to the
> spec? Please let me know one way or the other.
>
> thanks,
>
> -Linda
>
>
> On 3/7/2011 1:20 PM, Linda DeMichiel wrote:
>> In JPA 2.0 we extended the criteria API with the CriteriaBuilder
>> function method
>> <T> Expression<T> function (String name, Class<T> type, Expression<?>...
>> args);
>> with the expectation that we would add similar support to JPQL in this
>> release.
>> The Criteria API currently doesn't specify whether we meant to support
>> aggregate/table functions via this mechanism as well as scalar
>> functions, although the syntax supports it. We need to discuss this,
>> and, assuming that we do support it, we need to clarify this point in
>> the spec.
>> I would propose that we support both scalar and aggregate functions in
>> JPQL as well as in the criteria API.
>> Here's a strawman syntax for JPQL to kick off the discussion
>> FUNC(function_name, arg1, ..., argn)
>> Function_name is a string that denotes the database function that is
>> to be invoked.
>> Example:
>> SELECT c
>> FROM Customer c
>> WHERE FUNC("hasGoodCredit", c.balance, c.creditLimit)
>> The arguments must be suitable for the database function that is to be
>> invoked.
>> The result of the function must be suitable for the invocation
>> context.
>> The function may be a database-defined function or a user-defined
>> function.
>> Opinions?
>> thanks,
>> -Linda