OpenJPA
  1. OpenJPA
  2. OPENJPA-6

OpenJPA doesn't meaningfully implement JDBC3, JDBC4 methods in its delegates

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.0
    • Component/s: jdbc
    • Labels:
      None

      Description

      OpenJPA's JDBC wrappers throw UnsupportedOperationException for all the JDBC3 and JDBC4 methods. While OpenJPA doesn't use any of these methods, our mechanism for implementing them is limiting, in that users who obtain Connections from OpenJPA 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.

        Issue Links

          Activity

          Patrick Linskey created issue -
          Patrick Linskey made changes -
          Field Original Value New Value
          Link This issue is a clone of OPENJPA-5 [ OPENJPA-5 ]
          Patrick Linskey made changes -
          Priority Major [ 3 ] Minor [ 4 ]
          Description 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.
          OpenJPA's JDBC wrappers throw UnsupportedOperationException for all the JDBC3 and JDBC4 methods. While OpenJPA doesn't use any of these methods, our mechanism for implementing them is limiting, in that users who obtain Connections from OpenJPA 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.
          Kevin Sutter made changes -
          Link This issue relates to OPENJPA-114 [ OPENJPA-114 ]
          Milosz Tylenda made changes -
          Link This issue is duplicated by OPENJPA-1703 [ OPENJPA-1703 ]
          Milosz Tylenda made changes -
          Assignee Milosz Tylenda [ milosz ]
          Milosz Tylenda made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Milosz Tylenda made changes -
          Component/s jdbc [ 12311300 ]
          Milosz Tylenda made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Fix Version/s 2.1.0 [ 12314542 ]
          Resolution Fixed [ 1 ]
          Michael Dick made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Milosz Tylenda
              Reporter:
              Patrick Linskey
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development