Home » Eclipse Projects » DTP » JDBCSchemaLoader, JDBCTableLoader, etc. broken for many drivers.
| JDBCSchemaLoader, JDBCTableLoader, etc. broken for many drivers. [message #48135] |
Mon, 04 August 2008 16:27  |
Eclipse User |
|
|
|
Originally posted by: chris.enterprise-elements.com
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
|
|
|
| Re: JDBCSchemaLoader, JDBCTableLoader, etc. broken for many drivers. [message #48192 is a reply to message #48135] |
Tue, 05 August 2008 10:22  |
| Eclipse User |
|
|
|
Originally posted by: brianf.sybase.com
Hi Chris...
Well, we're always on the lookout for improvements in how we handle the
generics.
Go ahead and register a BZ enhancement request with some information about
how you think it should be done and we can consider it for the next major
release. This kind of wholesale change is too much for either of the
maintenance releases coming up, but we could look at it for Galileo (June
2009).
It might help to have some code examples of how you'd like to see things
done as well.
Thanks! Looking forward to more of your input!
--Fitz
"Chris Hines" <chris@enterprise-elements.com> wrote in message
news:g77ont$i2$1@build.eclipse.org...
>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
>
|
|
|
| Re: JDBCSchemaLoader, JDBCTableLoader, etc. broken for many drivers. [message #592422 is a reply to message #48135] |
Tue, 05 August 2008 10:22 |
| Eclipse User |
|
|
|
Hi Chris...
Well, we're always on the lookout for improvements in how we handle the
generics.
Go ahead and register a BZ enhancement request with some information about
how you think it should be done and we can consider it for the next major
release. This kind of wholesale change is too much for either of the
maintenance releases coming up, but we could look at it for Galileo (June
2009).
It might help to have some code examples of how you'd like to see things
done as well.
Thanks! Looking forward to more of your input!
--Fitz
"Chris Hines" <chris@enterprise-elements.com> wrote in message
news:g77ont$i2$1@build.eclipse.org...
>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
>
|
|
|
Goto Forum:
Current Time: Sun Jul 27 07:06:55 EDT 2025
Powered by FUDForum. Page generated in 0.05507 seconds |
Home