OpenJPA
  1. OpenJPA
  2. OPENJPA-1668

User's ''DBDictionary.sequenceSQL' setting not being honored on zOS

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0.3, 1.2.2, 2.0.0
    • Fix Version/s: 1.2.3, 1.3.0, 2.0.1, 2.1.0
    • Component/s: None
    • Labels:
      None

      Description

      When setting/overriding the 'DBDictionary.sequenceSQL' value via a property in the persistence.xml file, as follows:

      <property name="openjpa.jdbc.DBDictionary" value="db2(sequenceSQL='SELECT SCHEMA AS SEQUENCE_SCHEMA, NAME AS SEQUENCE_NAME FROM CIDB2.SYSSEQUENCES')"/>

      this value is not used when running DB2 on zOS. Rather, the 'default for zOS' is used, i.e.: "SELECT SCHEMA AS SEQUENCE_SCHEMA, NAME AS SEQUENCE_NAME FROM SYSIBM.SYSSEQUENCES";.

      To understand how this is happening, let me describe how 'sequenceSQL' is defined/set at runtime. First, the ctor of DB2Dictionary is called, and the variable is set to a default:

      sequenceSQL = "SELECT SEQSCHEMA AS SEQUENCE_SCHEMA, "
      + "SEQNAME AS SEQUENCE_NAME FROM SYSCAT.SEQUENCES";

      After the DB2Dictionary ctor is called, openJPA assigns to 'sequenceSQL' the value defined in the system property. So at this point things are all good and the variable is set to what is defined in the prop. Where things go awry is when the method DB2Dictionary.connectedConfiguration is called. In the method there is some platform specific code which is executed which overwrites the sequenceSQL value:

      // platform specific settings
      switch (db2ServerType) {
      case db2ZOSV8xOrLater:
      ........
      sequenceSQL = "SELECT SCHEMA AS SEQUENCE_SCHEMA, "
      + "NAME AS SEQUENCE_NAME FROM SYSIBM.SYSSEQUENCES";

      Thanks,

      Heath

        Activity

        Hide
        Michael Dick added a comment -

        This is a case where I wish we had a separate DBDictionary class for Z/OS (although we can't detect it until we have a connection so that would pose its own challenges).

        That said we shouldn't override user settings - the connectedConfiguration method needs to take user settings into account before overwriting the variables. AFAIK there isn't a good way to detect whether a config property was set by the user or just accepted the default value though - so solving the problem might be more kludgy than we'd like.

        I'd vote for checking whether sequenceSQL has the default value in connectedConfiguration. If it has the default we'll go ahead and override with a z/os default. If it isn't the default we'll leave it alone (maybe issue a trace statement).

        Any other ideas I've missed?

        Show
        Michael Dick added a comment - This is a case where I wish we had a separate DBDictionary class for Z/OS (although we can't detect it until we have a connection so that would pose its own challenges). That said we shouldn't override user settings - the connectedConfiguration method needs to take user settings into account before overwriting the variables. AFAIK there isn't a good way to detect whether a config property was set by the user or just accepted the default value though - so solving the problem might be more kludgy than we'd like. I'd vote for checking whether sequenceSQL has the default value in connectedConfiguration. If it has the default we'll go ahead and override with a z/os default. If it isn't the default we'll leave it alone (maybe issue a trace statement). Any other ideas I've missed?
        Hide
        Heath Thomann added a comment -

        I'm attaching a patch (OPENJPA-1668-1.2.x.patch.txt) for 1.2.x.

        Show
        Heath Thomann added a comment - I'm attaching a patch ( OPENJPA-1668 -1.2.x.patch.txt) for 1.2.x.
        Hide
        Michael Dick added a comment -

        Closing issues which have been resolved for some time. If the problem persists, please reopen.

        Show
        Michael Dick added a comment - Closing issues which have been resolved for some time. If the problem persists, please reopen.

          People

          • Assignee:
            Heath Thomann
            Reporter:
            Heath Thomann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development