[JBoss JIRA] Created: (TEIID-522) JDBC DatabaseMetadata methods do not accept empty string as catalog name
by Greg Haber (JIRA)
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
Environment: http://anonsvn.jboss.org/repos/teiid/trunk/client-jdbc/src/main/java/com/... rev 809
Reporter: Greg Haber
Assignee: Steven Hawkins
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
15 years, 7 months
[JBoss JIRA] Created: (TEIID-529) Simplify ConnectorCapabilities
by Steven Hawkins (JIRA)
Simplify ConnectorCapabilities
------------------------------
Key: TEIID-529
URL: https://jira.jboss.org/jira/browse/TEIID-529
Project: Teiid
Issue Type: Quality Risk
Components: Connector API
Affects Versions: 6.0.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 6.1.0
In making the other connector changes I would like to open a dialog on refining the connector capabilities mechanism. At a minimum I would like to just use basicconnectorcapabilities rather than having the connectorcapabilities interface, which noonne is told to implement directly anyway. A more aggressive approach would be to use the same approach as dqp, a map with an enum key.
--
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
15 years, 8 months
[JBoss JIRA] Created: (TEIID-493) Define a new modeling construct that can create a defaulted parameter.
by John Doyle (JIRA)
Define a new modeling construct that can create a defaulted parameter.
----------------------------------------------------------------------
Key: TEIID-493
URL: https://jira.jboss.org/jira/browse/TEIID-493
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Reporter: John Doyle
Assignee: Steven Hawkins
Priority: Minor
I would like to be able to define on a physical model a defaulted parameter value for a column, much like an access pattern with a default value. At runtime the default value would be sent as a parameter if the user did not supply a value in the query.
The use case that brought this to mind is the Salesforce connector. Each Salesforce object exposes a isDeleted column and since most uses of the connector do not want to see deleted objects, the user will have to know that they need to have isDeleted=false in the query. Having a 'defaulted access pattern' would allow us to encapsulate this SF API leakage better.
--
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
15 years, 8 months