[teiid-issues] [JBoss JIRA] Commented: (TEIID-522) JDBC DatabaseMetadata methods do not accept empty string as catalog name

[Greg Haber (JIRA)]

    [ https://jira.jboss.org/jira/browse/TEIID-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12463561#action_12463561 ] 

Greg Haber commented on TEIID-522:
----------------------------------

The intention was for the Teiid team to pick it up.

lliang checked in the work for this for 5.5SP2 back on 8/28/08, and it was also in 5.5SP3 GA - I'm not sure why his change was not picked up when Teiid was forked off of the MetaMatrix code (according to svn the initial checkin of MMDatabaseMetaData.java  was 11/5/2008).

This is actually a larger concern - since this is one example of 5.5SP2/3 work that didn't make it into Teiid, I wonder if there are others.  Looking through mail I see the following message from rreddy on 11/10/08:

"This is the call to all developers to merge your changes from either
5.5.3 or cases work into current Federate SVN repository."

which implies that the (pre-public) federate branch was done sometime between 5.5.2 GA and 5.5.3 GA, and that we relied on manual merges by the original committers of any changes after the branch.

Perhaps it would make sense to have a tracking JIRA to review all changes to 5.5.x after the branch, and do one of a) verify the equivalent change was indeed made in Teiid, b) port them over to Teiid, or c) explicitly decide not to pull over each individual change?

My concern is that when Teiid is used down the line for future commercial versions, we'll see regressions in the future versions because of such missed merges.

Not sure if such a tracking JIRA belongs under TEIID or JBEDSP projects...

Thanks,

Greg


> JDBC DatabaseMetadata methods do not accept empty string as catalog name 
> -------------------------------------------------------------------------
>
>                 Key: TEIID-522
>                 URL: https://jira.jboss.org/jira/browse/TEIID-522
>             Project: Teiid
>          Issue Type: Bug
>          Components: JDBC Driver
>    Affects Versions: 6.0.0
>         Environment: http://anonsvn.jboss.org/repos/teiid/trunk/client-jdbc/src/main/java/com/metamatrix/jdbc/MMDatabaseMetaData.java rev 809
>            Reporter: Greg Haber
>            Assignee: Steven Hawkins
>             Fix For: 6.1.0
>
>
> This is related to internal support ticket I-T #212065 (which was against MetaMatrix 5.5SP2).
> To resolve that ticket (where a third party software package expected different behavior from the MetaMatrix JDBC driver than it actually had), we made three changes:
> 1) DatabaseMetaData.supportsSchemaInDataManipulation() was changed to return true (which is correct) - looks like this change was also brought over to Teiid
> 2) DatabaseMetaData.supportsCatalogInDataManipulation() was changed to return the value of the boolean driver property "supportsCatalog".  This change didn't come over to Teiid (in Teiid this method always returns "false").  I'm fine with the current Teiid behavior, since we don't have a notion of catalog, so really "false" is the correct response here.
> 3)  The DatabaseMetaData methods getColumns, getExportedKeys, getImportedKeys, getIndexInfo, getPrimaryKeys, getProcedureColumns, getProcedures, and getTables all have a parameter for catalog name.  In the current Teiid implementation of MMDatabaseMetaData, if catalog is non-null an empty response is returned.  
> This is actually incorrect behavior according to both 1.5 and 1.6 javadoc - see http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getTables(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String[]) where it says:
> catalog - a catalog name; must match the catalog name as it is stored in the database; "" retrieves those without a catalog; null means that the catalog name should not be used to narrow the search
> So, since Teiid does not have the notion of a catalog, it should accept either null or the empty string as valid values for the catalog parameter.
> In the MMx 5.5.x code base, all of these methods were changed to only return empty responses if catalog was non-null, and also was not the empty string:
> if ((catalog != null) && (catalog.length() > 0)) {
> This same change should be made to Teiid.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira