Markus,
You are reading too deeply here.
What the Java EE spec is defining is the minimum requirements for a JDBC
driver in a Java EE environment.
The JPA spec, JSR 220, makes no requirement that a JPA implementation
must be based on JDBC. Because of this, you cannot assume there is any
linkage between JDBC Escapes and JPA.
The Java EE 5 specification also does not require JPA to use JDBC so you
cannot rely on the behavior as you desire.
Regards
Lance
Markus KARG wrote:
> 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
>>
>