DdlUtils
  1. DdlUtils
  2. DDLUTILS-235

Platform.alterTables detects way too many changes

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      When creating an ALTER-Script from two identical databases-Models obtained from an unchanged HSQLDB-Database (using the same database-model also does the trick), all SQLBuilders of all Platforms I've tried (including the HSQDB-Platform) generate SQL-Output, that creates temporary tables for each table, copies the content of the original tables into the temporary ones, drops the old tables, creates everything anew and copies the data back again recreating all constraints like they have been before.

      That is quite a lot of work for actually not changing anything.

      I've debugged a bit and found out, that the ModelComparator detects column-type changes by mapping the source-model's type via the platformspecific typemappings to the type of the target model (which remains unmapped).

      if (_platformInfo.getTargetJdbcType(targetColumn.getTypeCode()) != sourceColumn.getTypeCode())
      {
      changes.add(...);
      }

      This seems like a bug to me.

      Please correct me if I'm wrong, but I thought that a ddl-Database, as a model, does not include any specifications about the type or configuration of the database it has been extracted from. When comparing two databases for changes, the comparisions should then also be free of platform specific details. Those are only necessary when generating the SQL-Statements implementing the detected changes.

      I've patched the ModelComparator by changing the aforementioned line to

      if (targetColumn.getTypeCode() != sourceColumn.getTypeCode())
      {
      changes.add(...);
      }

      and now the Changedetection works like I would expect it to do (no changes on identical models, no unnecessary table- or contraint-drops).

        Activity

        Hide
        Frank Jakop added a comment -

        I agree with Björn, I had the same problem when running against an unchanged MSSQL-Database.

        When comparing, on the one hand the TypeCode of the column is used, on the other hand the TypeCode is transformed by getTargetJdbcType(). In my case, the CLOB-Type is defined in MSSqlPlatform to be mapped on LONGVARCHAR, so the comparison of CLOB (Type 2005) with TargetJdbcType(CLOB), which is LONGVARCHAR (Type -1) always yields false and a change is detected.

        MSSqlPlatform ()

        { [....] info.addNativeTypeMapping(Types.CLOB, "TEXT", Types.LONGVARCHAR); [....] }

        Either the mapping or the comparison have to be improved.

        Show
        Frank Jakop added a comment - I agree with Björn, I had the same problem when running against an unchanged MSSQL-Database. When comparing, on the one hand the TypeCode of the column is used, on the other hand the TypeCode is transformed by getTargetJdbcType(). In my case, the CLOB-Type is defined in MSSqlPlatform to be mapped on LONGVARCHAR, so the comparison of CLOB (Type 2005) with TargetJdbcType(CLOB), which is LONGVARCHAR (Type -1) always yields false and a change is detected. MSSqlPlatform () { [....] info.addNativeTypeMapping(Types.CLOB, "TEXT", Types.LONGVARCHAR); [....] } Either the mapping or the comparison have to be improved.
        Hide
        Eirik Bjorsnos added a comment -

        Any change this issue can be looked into? The fix seems easy enough if there's no side effects.

        This issue is more or less blocking my attempt at making a database diffing UI on top of DDLUtils.

        Show
        Eirik Bjorsnos added a comment - Any change this issue can be looked into? The fix seems easy enough if there's no side effects. This issue is more or less blocking my attempt at making a database diffing UI on top of DDLUtils.
        Hide
        Eirik Bjorsnos added a comment -

        Note that PlatformInfo.getTargetJdbcType is also called from:

        ColumnDefinitionChange.isSizeChanged
        ColumnDefinitionChange.isSizeReduced
        ColumnDefinitionChange.isTypeChanged

        as well as:

        ModelComparator.compareColumns
        MSSqlModelComparator.getRelevantChangedColumns
        PlatformImplBase.getObjectFromResultSet
        SqlBuilder.columnsDiffer

        So there's probably more than just one comparison that will need to be addressed to fix this issue.

        Show
        Eirik Bjorsnos added a comment - Note that PlatformInfo.getTargetJdbcType is also called from: ColumnDefinitionChange.isSizeChanged ColumnDefinitionChange.isSizeReduced ColumnDefinitionChange.isTypeChanged as well as: ModelComparator.compareColumns MSSqlModelComparator.getRelevantChangedColumns PlatformImplBase.getObjectFromResultSet SqlBuilder.columnsDiffer So there's probably more than just one comparison that will need to be addressed to fix this issue.

          People

          • Assignee:
            Thomas Dudziak
            Reporter:
            Björn Schmidt
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development