There is no requirement in JSR 220 spec that EJB 3 or JPA are to be
tied to a specific version of JDBC, or JDBC at all for that matter.
The Java EE 5 specification, like its previous versions, specify a
minimal set of JDBC functionality as well as JDBC version that is
required to be part of a compliant Java EE configuration.
Starting with Java EE 6, the JDBC requirements in a Java EE environment
will be defined in the JDBC specification. JDBC 4.0 has added these
requirements, expanding and clarifying the requirements in previous
versions of the Java EE specifications. Supporting JDBC escape syntax
while nice, is not a required by the JPA/EJB specification.
Regards
Lance
Markus KARG wrote:
> 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
>>>
>>>
>>
>