[JBoss JIRA] (TEIID-2800) Teiid Login Issue with special characters
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2800?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2800:
---------------------------------------
How are you using the URL - on a connection pool setting for example? If I enter a similar url directly for a TeiidDriver connection, then we handle the user name in its decoded form %flow012. So I suspect another layer may be in play here.
> Teiid Login Issue with special characters
> -----------------------------------------
>
> Key: TEIID-2800
> URL: https://issues.jboss.org/browse/TEIID-2800
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.1
> Environment: Mainframe Jboss 7.1.1
> Reporter: Gautam Banerjee
> Assignee: Steven Hawkins
>
> When we try to login to teiid programmatically through datasource, we are having problem with username having special characters.
> We are encoding the special character as per url encoding
> eg : username %xyz is encoded as %25xyz but teiid does not decode the special character while passing username. So the username passed by teiid is %25xyz which fails authentication as the actual username is %xyz
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (TEIID-2785) Update ModeShape jdbc translator to return the JCR procedures in the getMetadatda() call
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2785?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2785:
---------------------------------------
> Adding as a SYS, IMO, wouldn't be correct
That's the current behavior though. If you recall in the old mmx days functions regardless of their source were globally defined. In this case having them be SYS.JCR implies they are for a specific purpose. And even if they are scoped to a model you can still attempt to invoke them against another source. Again the rationale for this is introducing a single function definition rather than having each model with its own.
> Otherwise, there's no where to get the function details using metadata.
That an issue with Designer usage. In a dynamic vdb (or even a live designer vdb) the pushdown function metadata gets injected just like the schema scoped metadata, so it's there at runtime. For design time we have a couple of options, the simpliest of which is to add an import option to include the pushdown functions in the schema metadata (although it would be nice if the resolver knew the relationship between the function definitions). Beyond that designer would have to know how to update the function library based upon the translator set in use.
> Update ModeShape jdbc translator to return the JCR procedures in the getMetadatda() call
> ----------------------------------------------------------------------------------------
>
> Key: TEIID-2785
> URL: https://issues.jboss.org/browse/TEIID-2785
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector
> Affects Versions: 8.7
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 8.7
>
>
> The ModeShapeExecutionFactory should expose the JCR procedures in the metadata when the getMetadata(..) is called.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (TEIID-2800) Teiid Login Issue with special characters
by Gautam Banerjee (JIRA)
[ https://issues.jboss.org/browse/TEIID-2800?page=com.atlassian.jira.plugin... ]
Gautam Banerjee commented on TEIID-2800:
----------------------------------------
The url looks like this. The login username is %flow012 which is encoded to %25flow012 and passed to the url.
jdbc:teiid:Chorus;VirtualDatabaseVersion=1;PassthroughAuthentication=false;ApplicationName=JDBC;user=%25flow012;fetchSize=2048;autoCommitTxn=OFF;VirtualDatabaseName=Chorus;partialResultsMode=true;password=%25flow012
> Teiid Login Issue with special characters
> -----------------------------------------
>
> Key: TEIID-2800
> URL: https://issues.jboss.org/browse/TEIID-2800
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.1
> Environment: Mainframe Jboss 7.1.1
> Reporter: Gautam Banerjee
> Assignee: Steven Hawkins
>
> When we try to login to teiid programmatically through datasource, we are having problem with username having special characters.
> We are encoding the special character as per url encoding
> eg : username %xyz is encoded as %25xyz but teiid does not decode the special character while passing username. So the username passed by teiid is %25xyz which fails authentication as the actual username is %xyz
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (TEIID-2786) ModeShape ExecutionFactory.getMetadata fails with java.sql.SQLFeatureNotSupportedException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2786?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2786:
----------------------------------
Attachment: mode.patch
Here's a minimal patch pulling out TEIID-2785. We don't want too much of the internals of this class exposed as each extension point becomes something that we have to support for quite a while.
Some of the property defaults, such as useFullSchemaName, should not be changed as they are for the metadata presentation and do not affect how the metadata is fetched.
What is the rationale of overriding the table types? Typically specifying no table types (null) would mean getting all, rather than just VIEW. Specifying empty seems like it should return nothing.
Generally catching a sql feature not supported exception doesn't really work as you don't know what the calling sequence was that triggered the exception - you may be getting an invalid metadata subset.
Also ideally correcting the widenUnsignedTypes setter would be done in a separate issue so that it could be pulled back more easily as an individual change.
> ModeShape ExecutionFactory.getMetadata fails with java.sql.SQLFeatureNotSupportedException
> ------------------------------------------------------------------------------------------
>
> Key: TEIID-2786
> URL: https://issues.jboss.org/browse/TEIID-2786
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 7.7
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 8.7
>
> Attachments: mode.patch
>
>
> When trying to use the Teiid Designer feature of importing using a Teiid Connection fails when the connection is to ModeShape. The following exception:
> 08:33:44,914 ERROR [stderr] (teiid-async-threads - 2) java.sql.SQLFeatureNotSupportedException
> 08:33:44,915 ERROR [stderr] (teiid-async-threads - 2) at org.modeshape.jdbc.JcrMetaData.getTypeInfo(JcrMetaData.java:1656)
> 08:33:44,915 ERROR [stderr] (teiid-async-threads - 2) at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:107)
> 08:33:44,915 INFO [org.jboss.as.server] (management-handler-thread - 4) JBAS018559: Deployed "importVDB-vdb.xml" (runtime-name : "importVDB-vdb.xml")
> 08:33:44,916 ERROR [stderr] (teiid-async-threads - 2) at org.teiid.translator.jdbc.modeshape.ModeShapeExecutionFactory.getMetadata(ModeShapeExecutionFactory.java:280)
> 08:33:44,916 ERROR [stderr] (teiid-async-threads - 2) at org.teiid.translator.jdbc.modeshape.ModeShapeExecutionFactory.getMetadata(ModeShapeExecutionFactory.java:62)
> 08:33:44,916 ERROR [stderr] (teiid-async-threads - 2) at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:61)
> 08:33:44,917 ERROR [stderr] (teiid-async-threads - 2) at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55)
> 08:33:44,917 ERROR [stderr] (teiid-async-threads - 2) at org.teiid.jboss.VDBService$6.run(VDBService.java:397)
> 08:33:44,917 ERROR [stderr] (teiid-async-threads - 2) at org.teiid.jboss.VDBService$7.run(VDBService.java:444)
> 08:33:44,918 ERROR [stderr] (teiid-async-threads - 2) at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
> My guess is the local modeshape jdbc driver hasn't been fully vetted in this area, as the remote JDBC version has been the one used when using the Modeshape eclipse plugin for importing the metadata.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (TEIID-2785) Update ModeShape jdbc translator to return the JCR procedures in the getMetadatda() call
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2785?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2785:
---------------------------------------
Actually these procedures are already pushdown functions. From what I can see I don't believe they should be modeled as procedures as there is already special handling for the function calls.
What you may be getting at here is that we haven't yet rationalized the use of pushdown functions with designer. On the Teiid side a pushdown function is effectively scoped to the translator, not the model, since the metadata is under SYS. For example, SYS.JCR.JCR_CONTAINS. This then is a single function definition that is shared across all modeshape translators.
The simplest alternative is to have the same function redeclared on each model.
> Update ModeShape jdbc translator to return the JCR procedures in the getMetadatda() call
> ----------------------------------------------------------------------------------------
>
> Key: TEIID-2785
> URL: https://issues.jboss.org/browse/TEIID-2785
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector
> Affects Versions: 8.7
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 8.7
>
>
> The ModeShapeExecutionFactory should expose the JCR procedures in the metadata when the getMetadata(..) is called.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (TEIID-2801) HIVE2: HAVING specified without GROUP BY
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2801?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2801.
-----------------------------------
Fix Version/s: 8.7
Resolution: Done
The initial fix TEIID-2804 is sufficient to address this internal issue, but it still needs to be addressed since the user could issue a having query without a group by directly and still encounter this exception. This commit here removes general hive support for having and opt for the general engine workaround of using an inline view.
> HIVE2: HAVING specified without GROUP BY
> -----------------------------------------
>
> Key: TEIID-2801
> URL: https://issues.jboss.org/browse/TEIID-2801
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.6
> Environment: Teiid with HIVE1 and HIVE2
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
> Labels: teiid
> Fix For: 8.7
>
>
> If SQL contains HAVING, with group by.
> HIVE2 will throw the following exception:
> HAVING specified without GROUP BY, errorCode:40000, SQLState:42000)
> at org.apache.hadoop.hive.service.ThriftHive$execute_result$execute_resultStandardScheme.read(ThriftHive.java:1494)
> at org.apache.hadoop.hive.service.ThriftHive$execute_result$execute_resultStandardScheme.read(ThriftHive.java:1480)
> at org.apache.hadoop.hive.service.ThriftHive$execute_result.read(ThriftHive.java:1430)
> at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
> at org.apache.hadoop.hive.service.ThriftHive$Client.recv_execute(ThriftHive.java:116)
> at org.apache.hadoop.hive.service.ThriftHive$Client.execute(ThriftHive.java:103)
> at org.apache.hadoop.hive.jdbc.HivePreparedStatement.executeImmediate(HivePreparedStatement.java:175)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (TEIID-2802) HIVE2: got Invalid table alias or column reference when running UNION ALL query on HIVE2
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2802?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2802:
---------------------------------------
Based upon the doc it seems like this should be supported. So either there's an issue with their support of nested inline views or it's complaining about the group by or order by column reference. Ivan can you retry without the order by / group by?
> HIVE2: got Invalid table alias or column reference when running UNION ALL query on HIVE2
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-2802
> URL: https://issues.jboss.org/browse/TEIID-2802
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.6
> Environment: TEIID with HIVE2
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
> Labels: teiid
>
> If I tried to combine 2 tables from a same HIVE2 data source using UNION ALL, I got "Invalid table alias or column reference" error.
> Query that I submitted to Teiid originally:
> select "name"
> from (Select * from hive2.opportunities_small UNION ALL Select * from
> hive2.opportunities) "query"
> group by "name"
> order by "name"
> Query that Teiid generated:
> SELECT v_0.c_0 FROM (SELECT c_0 FROM (SELECT g_1.name AS c_0 FROM
> opportunities_small g_1 UNION ALL SELECT g_0.name AS c_0 FROM opportunities
> g_0) X__) v_0 GROUP BY v_0.c_0 ORDER BY v_0.c_0
> Error:
> Invalid table alias or column reference 'v_0': (possible column names are: c_0)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (TEIID-2804) Aggregate empty filter too broad and may inappropriately filter results
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2804?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2804.
-----------------------------------
Resolution: Done
Limited the scope of the empty row check to only situations where it is needed. Also corrected the check to only use count(*).
> Aggregate empty filter too broad and may inappropriately filter results
> -----------------------------------------------------------------------
>
> Key: TEIID-2804
> URL: https://issues.jboss.org/browse/TEIID-2804
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.3
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.7
>
>
> This is a regression from TEIID-2253 which consolidated logic in RulePushAggregates to handle multi-source planning. It also inappropriately expanded an empty test (which should only be applied to grouping without a group by) to some cases with group by clauses and in an attempt to broaden pushdown support utilized is not null tests. However the is not null tests are not generally valid as the aggregate could be computed against all null values for example. Depending upon this situations this could result in invalid filtering of results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (TEIID-2799) Import metadata from Object translator is not defining primary key
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2799?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2799.
-----------------------------------
Resolution: Done
Van added both selectable and non-selectable (a map entry where the key is not part of the object) primary keys.
> Import metadata from Object translator is not defining primary key
> ------------------------------------------------------------------
>
> Key: TEIID-2799
> URL: https://issues.jboss.org/browse/TEIID-2799
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Minor
> Fix For: 8.7
>
>
> The infinispan implementation of the object translator getMetadata is not defining the primary key. If the resource-adapter has defined it, it should expose it. This key is important for push-down capability. The user could define this after the fact (i.e, in dynamic vdb or in designer), but from a usability stand point, it would be better if the translator exposed it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months