Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-2094

Change REV_ value for insert statements to avoid problems on DB2 for zOS

    XMLWordPrintable

    Details

      Description

      In a current project using DB2 10.015 auf zOS the following statement does not execute:

      insert into ${prefix}ACT_RE_PROCDEF(ID_, REV_, CATEGORY_, NAME_, KEY_, VERSION_, DEPLOYMENT_ID_, RESOURCE_NAME_, DGRM_RESOURCE_NAME_, HAS_START_FORM_KEY_, SUSPENSION_STATE_)
      values (#

      {id, jdbcType=VARCHAR},
      1,
      #{category, jdbcType=VARCHAR},
      #{name, jdbcType=VARCHAR},
      #{key, jdbcType=VARCHAR},
      #{version, jdbcType=INTEGER},
      #{deploymentId, jdbcType=VARCHAR},
      #{resourceName, jdbcType=VARCHAR},
      #{diagramResourceName, jdbcType=VARCHAR},
      #{hasStartFormKey, jdbcType=BOOLEAN},
      #{suspensionState, jdbcType=INTEGER})

      Strangely it works if you either insert
      values (#{id, jdbcType=VARCHAR}

      ,
      '1',

      even if this is not a VARCHAR field. But it also works if you have the REV_ field at the end of the parameter list:

      <insert id="insertProcessDefinition" parameterType="org.camunda.bpm.engine.impl.persistence.entity.ProcessDefinitionEntity">
      insert into ${prefix}ACT_RE_PROCDEF(ID_, CATEGORY_, NAME_, KEY_, VERSION_, DEPLOYMENT_ID_, RESOURCE_NAME_, DGRM_RESOURCE_NAME_, HAS_START_FORM_KEY_, SUSPENSION_STATE_, REV_)
      values (#

      {id, jdbcType=VARCHAR}

      ,
      #

      {category, jdbcType=VARCHAR}

      ,
      #

      {name, jdbcType=VARCHAR}

      ,
      #

      {key, jdbcType=VARCHAR}

      ,
      #

      {version, jdbcType=INTEGER}

      ,
      #

      {deploymentId, jdbcType=VARCHAR}

      ,
      #

      {resourceName, jdbcType=VARCHAR}

      ,
      #

      {diagramResourceName, jdbcType=VARCHAR}

      ,
      #

      {hasStartFormKey, jdbcType=BOOLEAN}

      ,
      #

      {suspensionState, jdbcType=INTEGER}

      ,
      1)
      </insert>

      The latter could be changed in all MyBatis mappings and should not cause any trouble on other databases - it would remove the necessary patches in the current project.

      Actually I have not yet any idea why this is necessary on exactly this database - I will try to get some more information from the DBA after I logged the SQL statement created by MyBatis.

        Attachments

          Activity

            People

            Assignee:
            sebastian.menski Sebastian Menski
            Reporter:
            ruecker Bernd Rücker
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: