db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Schmidt (JIRA) <j...@apache.org>
Subject [jira] Created: (DDLUTILS-235) Platform.alterTables detects way too many changes
Date Wed, 03 Dec 2008 12:59:44 GMT
Platform.alterTables detects way too many changes  

                 Key: DDLUTILS-235
                 URL: https://issues.apache.org/jira/browse/DDLUTILS-235
             Project: DdlUtils
          Issue Type: Bug
          Components: Core (No specific database)
    Affects Versions: 1.0
            Reporter: Björn Schmidt
            Assignee: Thomas Dudziak
            Priority: Minor

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())

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()) 

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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message