You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Craig L Russell <Cr...@Sun.COM> on 2006/08/01 07:49:32 UTC

Re: [jira] Commented: (OPENJPA-6) OpenJPA doesn't meaningfully implement JDBC3, JDBC4 methods in its delegates

Hi Patrick,

I've changed the JIRA permissions so that openjpa-developers can do  
most useful JIRA actions.

Sadly, only brianm, clr, pcl, and geirm are openjpa-developers right  
now. Let me know the others' JIRA ids and I'll add them to the  
openjpa-developers list.

Craig

On Jul 31, 2006, at 10:33 PM, Patrick Linskey (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/OPENJPA-6? 
> page=comments#action_12424746 ]
>
> Patrick Linskey commented on OPENJPA-6:
> ---------------------------------------
>
> This issue should also be low-priority, but I do not seem to have  
> rights to (or knowledge of how to) change priorities.
>
>> OpenJPA doesn't meaningfully implement JDBC3, JDBC4 methods in its  
>> delegates
>> --------------------------------------------------------------------- 
>> -------
>>
>>                 Key: OPENJPA-6
>>                 URL: http://issues.apache.org/jira/browse/OPENJPA-6
>>             Project: OpenJPA
>>          Issue Type: Improvement
>>            Reporter: Patrick Linskey
>>
>> Patrick opines:
>> OpenJPA implements Statement, ResultSet, Connection, and maybe a
>> couple other JDBC interfaces. See
>> org.apache.openjpa.lib.jdbc.Delegating*. We do this for a number of
>> reasons: to resolve database-specific bugs in a transparent  
>> fashion, to
>> provide logging, to handle reference counting, etc.
>> The pressing issue is that we must provide implementations of all  
>> of the
>> methods in the various java.sql interfaces. The fact that we do not
>> implement the new JDBC4 methods is why OpenJPA won't currently  
>> compile
>> against JDK6. This is pretty easy to fix; take a look at
>> org.apache.openjpa.lib.jdbc.DelegatingStatement to see how we handled
>> this for JDBC3. Since we know that we never invoke the new  
>> methods, we
>> can happily throw unsupported operation exceptions for the new  
>> methods.
>> However, these unsupported methods do provide a challenge. While Kodo
>> doesn't use any of these methods, our mechanism for implementing  
>> them is
>> limiting, in that users who obtain Connections from Kodo will not be
>> able to use the new JDBC3/JDBC4 methods in their own code.  
>> Ideally, we
>> should provide some means for people to designate to OpenJPA that it
>> should use a dynamic proxy to implement the unimplemented methods.  
>> This
>> shouldn't be the default behavior, as the dynamic proxy will add
>> overhead, but certainly could be desirable for some. I'll file an  
>> issue.
>
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the  
> administrators: http://issues.apache.org/jira/secure/ 
> Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/ 
> software/jira
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!