OpenJPA
  1. OpenJPA
  2. OPENJPA-910

Allow multiple keys for the same property to be specified at different levels

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0-M1
    • Fix Version/s: None
    • Component/s: kernel
    • Labels:
      None

      Description

      In OPENJPA-850, support was provided for some 2.0 spec properties. Some of these properties are equivalent to current openjpa properties, resulting in some properties supported by 2 different keys. As part of this enhancement, an exception is thrown if the same property is specified more than once with different keys. An issue has been raised related to this suggesting that one key could be specified at one level (such as the persistence.xml) but another key could be specified at another level (such as a system property), and that we should allow this. This was discussed among several people, with the resulting conclusion documented by Pinaki as follows:

      Rule 1: OpenJPA configurations can be specified at following levels (from lowest to highest)
      I have changed Mike's order to reflect how the code (perhaps) now uses precedence (changing such order may require hard tweaks)
      > 1. openjpa.xml (globals)
      > 5. java.lang.System.getProperties()
      > 2. persistence.xml (<properties></properties>)
      > 3. A map passed in to the call to createEntityManagerFactory()
      > 4. A map passed in to getEntityManager()

      Rule 2: Each property is identified by a key. A key must have one, but can have multiple monikers. For example, 'ConnectionDriver' property has two monikers 'openjpa.ConnectionDriverName' and 'javax.persistence.jdbc.driver'. All monikers for a key are treated as interchangeable for all purpose other than when a key appears in the returned list of EMF.getProperties() – which is always the moniker whose corresponding value is 'in effect' in the configuration.

      Rule 3: If the same key is specified at the same level, a error message is generated.

      Rule 4: If the same key is specified at different levels, the higher level value overwrite the lower level value.
      INFO/TRACE message is printed if the values are overwritten or attempted to be overwritten respectively.

        Activity

        Hide
        Albert Lee added a comment -

        >> Rule 3: If the same key is specified at the same level, a error message is generated.

        Throwing an exception seems too harsh for the following reasons:

        1) Rule 2 says: "All monikers for a key are treated as interchangeable for all purpose.....", so we should treated all property instances the same.
        2) Based on 1), one property can override other, even with different prefix, at different levels. For consistency, this should work the same at the same level
        3) If 2 instances of the SAME property is specified in the same level, openjpa currently will take the last instance's value, so I lean toward keeping the same behavior.
        4) The argument against 3) is which instance of the multiple definitions will be used and how will user know which one is picked deterministically by openjpa. hence the proposed rule 3, thrown an exception. To address the concern, a warning can be issued indicating the value accepted and used by openjpa configuration would be sufficient.

        Albert Lee.

        Show
        Albert Lee added a comment - >> Rule 3: If the same key is specified at the same level, a error message is generated. Throwing an exception seems too harsh for the following reasons: 1) Rule 2 says: "All monikers for a key are treated as interchangeable for all purpose.....", so we should treated all property instances the same. 2) Based on 1), one property can override other, even with different prefix, at different levels. For consistency, this should work the same at the same level 3) If 2 instances of the SAME property is specified in the same level, openjpa currently will take the last instance's value, so I lean toward keeping the same behavior. 4) The argument against 3) is which instance of the multiple definitions will be used and how will user know which one is picked deterministically by openjpa. hence the proposed rule 3, thrown an exception. To address the concern, a warning can be issued indicating the value accepted and used by openjpa configuration would be sufficient. Albert Lee.

          People

          • Assignee:
            Unassigned
            Reporter:
            Dianne Richards
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development