[
https://jira.jboss.org/jira/browse/TEIID-522?page=com.atlassian.jira.plug...
]
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/...
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#getT...
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