[news.eclipse.dtp] JDBCSchemaLoader, JDBCTableLoader, etc. broken for ma

["Chris Hines" <chris@xxxxxxxxxxxxxxxxxxxxxxx>]

I have been researching the feasibility of using DTP as an enabling tool for 
a general purpose database metadata reporting/management application.  We 
already use EMF, so bringing in DTP seems quite natural.  I have encountered 
a significant roadblock using the GenericJDBC infrastructure.

I have discovered that the code in the 
org.eclipse.datatools.connectivity.sqm.loader package processes JDBC 
ResultSets in a non-portable fashion, making it fail when using many JDBC 
drivers, including the JDBC-ODBC bridge supplied as part of Sun's JVM.

The root problem is that DTP attempts to read the same column from a 
ResultSet object more than once (for the same row), which is not guaranteed 
to work as expected.  The javadoc for ResultSet says:  "For maximum 
portability, result set columns within each row should be read in 
left-to-right order, and each column should be read only once."

However, DTP uses the following code pattern:

[  Code snippet from JDBCTableLoader.loadTables(List containmentList, 
Collection existingTables)  ]

while (rs.next()) {
    String tableName = rs.getString(COLUMN_TABLE_NAME);      // first time 
to retrieve table_name
    if (tableName == null || isFiltered(tableName)) {
        continue;
    }
    Table table = (Table) getAndRemoveSQLObject(existingTables, tableName);
    if (table == null) {
        table = processRow(rs);                 // eventually calls 
tableFactory.initialize(table, rs) (see below)
        if (table != null) {
            containmentList.add(table);
        }
    }
    else {
        ITableFactory tableFactory = getTableFactory(rs
            .getString(COLUMN_TABLE_TYPE));
        if (tableFactory != null) {
            tableFactory.initialize(table, rs);     // retrieves table_name 
a second time
        }
        containmentList.add(table);
        if (table instanceof ICatalogObject) {
            ((ICatalogObject) table).refresh();
        }
    }
}

This pattern is pervasive throughout the 
org.eclipse.datatools.connectivity.sqm.loader package.

Does anyone have any suggestions about how to work around this problem? 
Should I enter this as a bugzilla entry?

Thanks,
Chris