db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Jakop (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DDLUTILS-235) Platform.alterTables detects way too many changes
Date Wed, 15 Apr 2009 13:15:14 GMT

    [ https://issues.apache.org/jira/browse/DDLUTILS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699182#action_12699182
] 

Frank Jakop commented on DDLUTILS-235:
--------------------------------------

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.

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

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


Mime
View raw message