Doctrine DBAL
  1. Doctrine DBAL
  2. DBAL-934

[GH-628] bug fix for db2 v10 new column def of syscat.columns.default

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      This issue is created automatically through a Github pull request on behalf of rehfeldchris:

      Url: https://github.com/doctrine/dbal/pull/628

      Message:

      It seems like ibm changed the column type of the column named "default" in syscat.columns in db2 luw v10. Probably in db2z too, but I haven't looked.

      in v9.7 it was VARCHAR(254)
      http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_9.7.0%2F2-10-7-17&lang=en

      in 10.1 its CLOB(64k)
      http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_10.1.0%2F2-9-8-18&lang=en

      This causes an sql statement to fail. In
      file: doctrine/dbal/lib/Doctrine/DBAL/Platforms/DB2Platform.php
      method: getListTableColumnsSQL()

      We make some sql like

      SELECT DISTINCT c.tabschema, c.tabname, c.colname, c.colno,
      c.typename, c.default, c.nulls, c.length, c.scale,
      c.identity, tc.type AS tabconsttype, k.colseq
      FROM syscat.columns c
      ...

      This causes an exception like:
      [IBM][CLI Driver][DB2/LINUXX8664] SQL0134N Improper use of a string column, host variable, constant, or function "DEFAULT". SQLSTATE=42907 SQLCODE=-134

      The key problem here seems to be that you can't include a CLOB column in a select distinct.

      At the very least, this breaks the command line tool for orm:schema-tool:update, although it might break other stuff too that I'm not aware of.

      There's probably a cleaner query we can use, but I'm not familiar with the code base and what can/can't change. I don't want to introduce a bug, so I took the safe route and just did the ugly
      subquery and join that shouldn't disturb anything. It's not like we need performance here.

      I added a test which compares the results of the previous query with my new one. Seems to work. The test isn't something I expect to be added to your test suite - I figure someone else will run it manually to confirm my changes and then delete the test.

        Issue Links

          Activity

          There are no comments yet on this issue.

            People

            • Assignee:
              Marco Pivetta
              Reporter:
              Doctrine Bot
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: