Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M2
    • Fix Version/s: 2.0.0-M1
    • Component/s: jpa
    • Labels:
      None

      Description

      Detection and storage of the JPA specification level will be necessary to help maintain backward compatibility with prior versions of OpenJPA. This item is to design and implement a solution to deterministically detect the version requested by the application (likely based on application artifacts such as the persistence.xml) and store the information such that OpenJPA can use the information at runtime to help maintain backward compatibility.

        Activity

        Hide
        Jeremy Bauer added a comment -

        Thoughts/suggestions provided by Pinaki:

        OpenJPAConfiguration already has a notion of specification – but it is merely a String.
        Follow the trail of ProductDerivation.afterSpecificationSet(String spec) and OpenJPAConfiguration.setSpecification(String spec).
        Currently Specification is set to "JPA", JDO" etc.
        We can consider
        a) introduce a internal Specification class with version info as some JDBC drivers do.
        b) overload OpenJPAConfiguration.setSpecification(String spec, int majorVersion, int minorVersion)

        Irrespective of the mechanics, the idea is to capture more data about which specification OpenJPA kernel is working with.
        Detection of which specification is active in runtime controlled by appropriate ProductDerivation but it is hardcoded and does not capture specification version.

        The work on schema upgrade for JPA 2.0 may lead to devising some mechanics on detecting specification version. If that is done satisfactorily and early enough (i.e. before configuration is set) during bootstrap, we can stick that version info with the Configuration. Then Compatibility and other stuff can set their defaults based on specification. Or annotation processing can warn on conflicting settings etc.

        Essentially,
        1. detect or accept user-supplied specification name & version.
        2. Plug it into OpenJPAConfiguration.
        3. Set default values of Compatibility and other stuff based on Specification
        4. Warn during annotation parsing if settings are conflicting etc.

        Show
        Jeremy Bauer added a comment - Thoughts/suggestions provided by Pinaki: OpenJPAConfiguration already has a notion of specification – but it is merely a String. Follow the trail of ProductDerivation.afterSpecificationSet(String spec) and OpenJPAConfiguration.setSpecification(String spec). Currently Specification is set to "JPA", JDO" etc. We can consider a) introduce a internal Specification class with version info as some JDBC drivers do. b) overload OpenJPAConfiguration.setSpecification(String spec, int majorVersion, int minorVersion) Irrespective of the mechanics, the idea is to capture more data about which specification OpenJPA kernel is working with. Detection of which specification is active in runtime controlled by appropriate ProductDerivation but it is hardcoded and does not capture specification version. The work on schema upgrade for JPA 2.0 may lead to devising some mechanics on detecting specification version. If that is done satisfactorily and early enough (i.e. before configuration is set) during bootstrap, we can stick that version info with the Configuration. Then Compatibility and other stuff can set their defaults based on specification. Or annotation processing can warn on conflicting settings etc. Essentially, 1. detect or accept user-supplied specification name & version. 2. Plug it into OpenJPAConfiguration. 3. Set default values of Compatibility and other stuff based on Specification 4. Warn during annotation parsing if settings are conflicting etc.
        Hide
        Pinaki Poddar added a comment -

        Considering it to resolved.
        Will reopen if needed when the Specification version facilities are being used by other parts.

        Show
        Pinaki Poddar added a comment - Considering it to resolved. Will reopen if needed when the Specification version facilities are being used by other parts.

          People

          • Assignee:
            Pinaki Poddar
            Reporter:
            Jeremy Bauer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved:

              Development