Hi Markus,
It is true that TopLink does not use JDBC escape functions. The
reason is simple. We have chosen, for the time being, not to force
users to use JDBC 3.0 drivers. I think this would be a good feature
request.
-Tom
Markus KARG wrote:
>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
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com