Tom Ware schrieb:
> 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.
OK, so I file one. Actually Java EE 5 is forcing JDBC 3.0, so I think
time has come to increase the pressure to vendors for beeing JDBC 3.0
compliant.
>
> -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
>>
>>
>