[JBoss JIRA] (TEIID-4824) Add unique id as a configuration property in the Google Resource adapter
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4824?page=com.atlassian.jira.plugin... ]
Work on TEIID-4824 started by Steven Hawkins.
---------------------------------------------
> Add unique id as a configuration property in the Google Resource adapter
> ------------------------------------------------------------------------
>
> Key: TEIID-4824
> URL: https://issues.jboss.org/browse/TEIID-4824
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Affects Versions: 8.12.8.6_3
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.3, 8.12.x-6.4
>
>
> Currently, only the google spreadsheet name can be used in the Google Resource adapter instead of the unique id of the document. If there is more than one document with same name in multiple folders the wrong file may be picked up by the resource adapter. Is it possible to use unique document ID instead of spreadsheet name for google data source
--
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 Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4875?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4875.
-----------------------------------
Resolution: Done
Changed the logic to recollect the aggregates when a modification is introduced that may affect other staged aggregates.
> 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
>
>
> 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
[JBoss JIRA] (TEIID-4824) Add unique id as a configuration property in the Google Resource adapter
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4824?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4824:
-------------------------------
Fix Version/s: 8.12.x-6.4
> Add unique id as a configuration property in the Google Resource adapter
> ------------------------------------------------------------------------
>
> Key: TEIID-4824
> URL: https://issues.jboss.org/browse/TEIID-4824
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Affects Versions: 8.12.8.6_3
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.3, 8.12.x-6.4
>
>
> Currently, only the google spreadsheet name can be used in the Google Resource adapter instead of the unique id of the document. If there is more than one document with same name in multiple folders the wrong file may be picked up by the resource adapter. Is it possible to use unique document ID instead of spreadsheet name for google data source
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Michael Echevarria (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Michael Echevarria updated TEIID-4858:
--------------------------------------
Workaround Description: Use simple-jdbc or override the orderBy option in the hive translator (was: Do not use the hive translator and only use jdbc)
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Michael Echevarria (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Michael Echevarria commented on TEIID-4858:
-------------------------------------------
Yep, the override worked perfectly. I attached a couple screenshots so that others could see where to make the changes in the designer if they chose to do so.
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Michael Echevarria (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Michael Echevarria updated TEIID-4858:
--------------------------------------
Attachment: override1.png
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Michael Echevarria (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Michael Echevarria updated TEIID-4858:
--------------------------------------
Attachment: override2.png
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
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 Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4875?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4875:
----------------------------------
Description:
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)
was:
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
Will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node.
> 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
>
>
> 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
[JBoss JIRA] (TEIID-4875) Planning issue with multiple aggregate decompositions through a join tree
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4875:
-------------------------------------
Summary: 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
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
Will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (TEIID-4874) SQL Server translator should support full outer join by default
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4874:
-------------------------------------
Summary: SQL Server translator should support full outer join by default
Key: TEIID-4874
URL: https://issues.jboss.org/browse/TEIID-4874
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.3, 9.2.3
Due to inheriting from the sybase translator, the sqlserver translator by default does not support full outer join. This should changed to true.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months