Lance J. Andersen schrieb:
> 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.
The Java EE 5 Specification contains the following:
<quote>
Drivers supporting the JDBC API in a Java EE environment must meet the
JDBC 3.0 API Compliance requirements as specified in the JDBC
specification and must meet a number of additional requirements in their
implementation of JDBC APIs, as described below:
...
A driver must support the Statement escape syntax for the following
functions
as specified by the JDBC specification:
■CONCAT
■SUBSTRING
■LOCATE (two argument version only)
■LENGTH
■ABS
■SQRT
■MOD
...
</quote>
For me this reads as "the driver must support JDBC 3.0, including this
escape functions".
I did never say that the EJB specification enforces JDBC 3.0, but I said
that Java EE 5, which EJB 3.0 is embraced by, enforces JDBC 3.0. Which I
still think is true.
Have Fun
Markus
>
> 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
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>