[JBoss JIRA] (TEIID-4849) Google translator behaves unexpectedly with Double in WHERE clause of SELECT
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4849?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4849.
-----------------------------------
Fix Version/s: (was: 10.0)
Resolution: Rejected
After reviewing this in light of TEIID-4854, this is not an issue. For the read case the user's worksheet can be in any locale - it is not expected that the values are formatted to SQL/Teiid literals. As long as the column is recognized as numeric, then the Teiid user query will work as expected.
> Google translator behaves unexpectedly with Double in WHERE clause of SELECT
> ----------------------------------------------------------------------------
>
> Key: TEIID-4849
> URL: https://issues.jboss.org/browse/TEIID-4849
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12.10.6_3
> Reporter: Lucie Fabrikova
> Priority: Minor
>
> Query like "SELECT DoubleNum FROM SmallA WHERE DoubleNum > 5.0" gives unexpected results for following values in DoubleNum column:
> * value like '15.1' is probably by google spreadsheet interpreted as date (in function row in sheet appears 15.1.2017), SELECT query returns no results
> * value like '150.1': SELECT returns null
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4893) Inconsistent behavior of SUBSTRING function
by dalex dalex (JIRA)
[ https://issues.jboss.org/browse/TEIID-4893?page=com.atlassian.jira.plugin... ]
dalex dalex commented on TEIID-4893:
------------------------------------
[~shawkins] that is SUBSTRING function modifier should be added for PostgreSQL translator to treat 0/negative indexes for SUBSTRING function, correct?
> Inconsistent behavior of SUBSTRING function
> -------------------------------------------
>
> Key: TEIID-4893
> URL: https://issues.jboss.org/browse/TEIID-4893
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 9.0.3
> Environment: teiid-9.0.3 on WildFly Full 9.0.2.Final (WildFly Core 1.0.2.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Priority: Critical
>
> There is inconsistent behavior of SUBSTRING function in teiid and data sources.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4893) Inconsistent behavior of SUBSTRING function
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4893?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4893:
----------------------------------
Component/s: JDBC Connector
(was: Query Engine)
Priority: Critical (was: Blocker)
> Or we should know that the SUBSTRING function works on teiid only by this way and that's all?
The core problem is with using a non-positive index. Since substring and the associated source functions aren't standard, there isn't consistent handling. We do though assume that the Teiid behavior is the defacto correct behavior and translator logic when possible should compensate. In this case the postgres translator is not accounting for 0/negative indexes and should be updated to account for that.
In general use 1 based indexing in string functions when possible.
> Inconsistent behavior of SUBSTRING function
> -------------------------------------------
>
> Key: TEIID-4893
> URL: https://issues.jboss.org/browse/TEIID-4893
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 9.0.3
> Environment: teiid-9.0.3 on WildFly Full 9.0.2.Final (WildFly Core 1.0.2.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Priority: Critical
>
> There is inconsistent behavior of SUBSTRING function in teiid and data sources.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4893) Inconsistent behavior of SUBSTRING function
by dalex dalex (JIRA)
dalex dalex created TEIID-4893:
----------------------------------
Summary: Inconsistent behavior of SUBSTRING function
Key: TEIID-4893
URL: https://issues.jboss.org/browse/TEIID-4893
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 9.0.3
Environment: teiid-9.0.3 on WildFly Full 9.0.2.Final (WildFly Core 1.0.2.Final)
Reporter: dalex dalex
Assignee: Steven Hawkins
Priority: Blocker
There is inconsistent behavior of SUBSTRING function in teiid and data sources.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4561) Deprecate the PassthroughIdentityLoginModule
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4561?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4561.
-----------------------------------
Resolution: Done
Since we could not reach consensus in the OAuth case, that will be left as requiring the PassthroughIdentityLoginModule.
> Deprecate the PassthroughIdentityLoginModule
> --------------------------------------------
>
> Key: TEIID-4561
> URL: https://issues.jboss.org/browse/TEIID-4561
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3
>
>
> The delegation capability of the PassthroughIdentityLoginModule can be associated with the underlying OAuth10/20 login modules (similar to the delegationCredential behavior of the KerberosLoginModule). Also the OAuthCredentialContext should be changed to use the Subject private credentials rather than a ThreadLocal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4892) oData v4 error using $expand
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4892?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4892.
-----------------------------------
Fix Version/s: 9.3
9.1.5
9.2.3
Resolution: Done
Fixed the code by making sure the buffer was not empty.
> oData v4 error using $expand
> ----------------------------
>
> Key: TEIID-4892
> URL: https://issues.jboss.org/browse/TEIID-4892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 9.1.4
> Environment: Teiid 9.1.4 with WildFly 10.0.0.Final running on Windows server 2012 R2 Datacenter Edition.
> Reporter: Marco Monti
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.1.5, 9.2.3
>
> Attachments: server.log
>
>
> Hello,
>
> we are querying Teiid 9.1.4 using the following oData v4 syntax:
>
> {{http://host:port/odata4/<vdbname>/<model-name>/<table-name>?$expand=<navigation>}}
>
> It doesn't matter what navigation property we choose; we always get following error message:
>
> {{{"error":{"code":null,"message":"String index out of range: -1"}}}}
>
> Please find the attached logfile.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4875) Planning issue with multiple aggregate decompositions through a join tree
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4875?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4875:
---------------------------------
Fix Version/s: 8.12.11.6_3
> Planning issue with multiple aggregate decompositions through a join tree
> -------------------------------------------------------------------------
>
> Key: TEIID-4875
> URL: https://issues.jboss.org/browse/TEIID-4875
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.2.3, 8.12.11.6_3
>
>
> The logic for determining other symbols from aggregates will not work correctly when a staged grouping is initially pushed and another staged grouping is then pushed above a join that is above that location (typically due to join predicates that pull in other groups).
> A query such as:
> SELECT max(t3.e4), max(t2.e4) as s FROM pm1.g1 as t1, pm1.g2 as t2, pm1.g3 as t3, pm1.g4 as t4, pm2.g1 as t5 WHERE t1.e1 = t2.e1 and (t2.e2 = t3.e2 and t1.e3 || t2.e3 = t3.e3) and t3.e3 = t4.e3 and t4.e4 = t5.e4
> With capabilities that disable join pushdown will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node.
> java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367)
> at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91)
> at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months