Uploaded image for project: 'OpenJPA'
  1. OpenJPA
  2. OPENJPA-442

JIRA-407 introduced backward compatibility problem in QueryImpl

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0, 1.2.0
    • Fix Version/s: 1.2.0
    • Component/s: query
    • Labels:
      None

      Description

      In the openjpa-407 patch, it changed the constructor to pass an extra parameter RuntimeExceptionTransaltor,

      public QueryImpl(EntityManagerImpl em, RuntimeExceptionTranslator ret,
      org.apache.openjpa.kernel.Query query)

      { _em = em; _query = new DelegatingQuery(query, ret); }

      However, it did not keep the orginial constructor so the extension of this QueryImpl from other vendor resulted in compiler error. We need to keep the backward compatibilty issue in mind when we change the public interface.
      The solution will be to add the original constructor back and route it to the new constructor:

      public QueryImpl(EntityManagerImpl em, RuntimeExceptionTranslator ret,
      org.apache.openjpa.kernel.Query query)

      { _em = em; if (ret == null) ret = PersistenceExceptions.getRollbackTranslator(em); _query = new DelegatingQuery(query, ret); }

      /**

      • Constructor; supply factory and delegate.
        */
        public QueryImpl(EntityManagerImpl em, org.apache.openjpa.kernel.Query query) { this(em, null, query); }

        Activity

        Hide
        tckan1 Teresa Kan added a comment -

        attach the patch.

        Show
        tckan1 Teresa Kan added a comment - attach the patch.
        Hide
        pcl Patrick Linskey added a comment -

        So I guess it depends what we consider to be a "public interface". To date, we've defined that as just being things that are marked as @published. Significantly increasing this footprint will make OpenJPA much more brittle to refactorings.

        We might want to think about a relatively high-speed deprecation route for things like this. This could help facilitate integration testing etc. while still allowing things to change as we perform useful refactorings by providing overlap in internal SPI compatibility.

        Show
        pcl Patrick Linskey added a comment - So I guess it depends what we consider to be a "public interface". To date, we've defined that as just being things that are marked as @published. Significantly increasing this footprint will make OpenJPA much more brittle to refactorings. We might want to think about a relatively high-speed deprecation route for things like this. This could help facilitate integration testing etc. while still allowing things to change as we perform useful refactorings by providing overlap in internal SPI compatibility.

          People

          • Assignee:
            mikedd Michael Dick
            Reporter:
            tckan1 Teresa Kan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development