Every SQL dialect has its own syntax for functions like CONCAT("Hot",
"Java"). To allow writing applications that are using these functions
without knowledge about the actual dialect's syntax (function name,
parameter sequence, etc.), JDBC 3.0 provides escape functions like {fn
concat("Hot", "Java"}. Following the constraints found in JDBC 3.0, a
driver MUST support a list of such functions provided in the
specification, to be "JDBC 3.0 compliant". Java EE 5, the embrace around
EJB 3.0, clearly says that JDBC 3.0 compliance is mandatory for a server
product to be "Java EE 5 compliant".
Following this argument chain, I was expecting the Java EE 5 reference
implementation, GlassFish, to make strong use of that JDBC escape
functions, since it should be fairly easy and straightforward to map
JPA's QL functions more or less 1:1 on JDBC escape functions. The
benefit would be: Easyness of implementation, and high performance --
since the application server itself (or: the JPA provider) doesn't need
to spend time into any logic of function name conversion, and since the
JDBC driver can just forward the SQL string to the server, which can do
the parsing and analyzing of the function (instead of parsing on the
client, which might be a slow machine compared to the fat server).
I was a bit astonished to see that TopLink doesn't make use of passing
through the unchanged JDBC escape functions. In fact, it depends of
there beeing a platform implementation that does the translation on the
JDBC-client side (here i. e. the application server). Moreover, it seems
to be impossible to tell TopLink that a client doesn't like to do a
translation: The minimum translation is to have a platform
implementation that translates from TopLink's internal representation
into JDBC escape functions - which is some kind of total overhead.
So am I right, is TopLink really not able to just pass through JDBC
escape functions? Do I really have to go all the way down into the
platform implementation, find out the correct String and parameter
sequence, build up the final String (which in fact CAN be JDBC escape
functions -- but does a lot of plumbing anyways)?
If that is true, please tell me. I will file a request for enhancement then.
If that is not true, please tell me. I will reduce SQLAnywherePlatform
and MaxDBPlatform to not do manual translation but JDBC escape functions
then. At least for SQLAnywhere I know that it is working, since I tried
it out some months ago.
Thanks a lot
Markus