A better example includes the Math functions (abs, sin, cos, cosh,
etc.) which are not in JPQL and are mostly conflicts with database
names.
--Gordon
Gordon Yorke wrote:
Actually all those keywords are already in JPQL. As is James' example.
--Gordon
Gordon Yorke wrote:
We actually have quite a few conflicts: 'concat, like, trim, locate,
etc.' and using case should be avoided as users expect JPQL to be case
insensitive and it would be an non-intuitive mechanism for users. A
better way would be to introduce another simple keyword like ELFUNC.
This functionality would also be valuable for users migrating their own
custom _expression_ framework functions they have created through the
ExpressionOperator class.
--Gordon
James Sutherland wrote:
The _expression_ operator names are normally not the db names, just logical/java names, like "ToLowerCase" not "UPPER". There are some that may conflict, but these would normally amount to the same thing being generated, we could check the number of arguments as well, as this is the only thing I can think of that may be different. If the user really wanted to override, and the operator name was the same, then they could give a different case as the operator names are mixed case, uppercase would revert to db.
We should also probably have a public list or set of statics define the supported platform independent functions we support.
-----Original Message-----
From: Tom Ware
Sent: Monday, March 08, 2010 9:18 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Re: Bug 300512 - Add FUNCTION support to extended JPQL
Should we provide some facility to allow users to use "FUNC" as an override for
functions we support? (i.e. if our implementation does not do what the user wants)
-Tom
James Sutherland wrote:
Can we also support platform independence for the function that we do
know about?
You can use the map in ExpressionOperator (getPlatformOperatorNames), to
find if there is a know operator for the function name, and then use the
operator to build the function.
-----Original Message-----
*From:* Andrei Ilitchev
*Sent:* Monday, March 08, 2010 7:14 AM
*To:* Dev mailing list for Eclipse Persistence Services
*Subject:* [eclipselink-dev] Re: Bug 300512 - Add FUNCTION support to
extended JPQL
Reworked FUNC following conversation with Peter: now the user can use any
database function they'd like and FuncNode creates FunctionExpression for it
"on the fly".
That means that the name passed to FUNC will be always used as function name
(there is no platform - based name traslation).
Also there is no type checking whatsoever.
Following conversation with James changed FunctionExpression.create
method so
that it sets as a locaBase an ExpressionBuilder - in case of
FunctionOperator;
also removed
public void printSQLWithoutConversion(ExpressionSQLPrinter printer) method.
Added a bunch of tests testing the standard JPA functions (ABS, MOD etc)
into
JUnitJPQLComplexTestSuite.
Because custom functions are platform-dependent the only way to test them is
currently in Oracle tests (because the function that works on MySQL probably
will fail on some other platform; but Oracle tests run on Oracle only).
Added to Oracle JPA tests CustomJPQLTestSuite (which currently contains a
single test for NVL but will grow later) and SpatialJPQLTestSuite (sdo).
----- Original Message -----
*
From: Andrei Ilitchev <mailto:andrei.ilitchev@xxxxxxxxxx>
*
**To:* Dev mailing list for Eclipse Persistence Services
<mailto:eclipselink-dev@xxxxxxxxxxx> *
**Sent:* Monday, March 01, 2010 6:09 PM*
**Subject:* Bug 300512 - Add FUNCTION support to extended JPQL *
* *
*https://bugs.eclipse.org/bugs/show_bug.cgi?id=300512*
* *
*This patch is prototype 3 patch + some clean up and tests added.
- defines a new key word FUNC to be used to define new JPQL functions;
- see the new class FuncNode for examples of custom functions:
NVL, TO_NUMBER, TO_DATE and four JGeometry (SDO) functions;
- added more type checking for standard jpa 2.0 functions;
- fixed a couple of adjacent bugs:
Bug 246598 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=246598> -
Unable to parse TRIM in JPA NamedQuery;
Bug 303540 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=303540> -
JPQL: query fails to compile if variable found only in function
parameters.*
* *
*Please send any feedback you may have.*
* *
*Thanks,*
* *
*Andrei <https://bugs.eclipse.org/bugs/show_bug.cgi?id=303540>*
*
*
------------------------------------------------------------------------
*
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
*
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
|
