OpenJPA
  1. OpenJPA
  2. OPENJPA-442

JIRA-407 introduced backward compatibility problem in QueryImpl

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major 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
        Teresa Kan added a comment -

        attach the patch.

        Show
        Teresa Kan added a comment - attach the patch.
        Hide
        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
        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:
            Michael Dick
            Reporter:
            Teresa Kan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development