[JBoss JIRA] (TEIID-5530) common tables used in only 1 location which is a subquery still inlined
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5530:
-------------------------------------
Summary: common tables used in only 1 location which is a subquery still inlined
Key: TEIID-5530
URL: https://issues.jboss.org/browse/TEIID-5530
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.0
With a query such as:
with x as (select ...)
select (select ... from x where ...) from y
The x common table is inlined even though it may be less efficient for processing.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5529) Non-pushed subquery may have evaluatable predicates not pushed
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5529:
-------------------------------------
Summary: Non-pushed subquery may have evaluatable predicates not pushed
Key: TEIID-5529
URL: https://issues.jboss.org/browse/TEIID-5529
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.0
For example, a source that does not support lower nor correlated subqueries and a query like:
SELECT array_agg((select intkey from bqt1.smallb where stringkey = lower(a.stringkey))) from bqt1.smalla a
will not push stringkey = lower(a.stringkey) to the n-many subquery, even though it can be pre-evaluated with the correlated value.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5528) Implement insert handling of arrays in PostgreSQL
by Vojtech Kolacek (Jira)
Vojtech Kolacek created TEIID-5528:
--------------------------------------
Summary: Implement insert handling of arrays in PostgreSQL
Key: TEIID-5528
URL: https://issues.jboss.org/browse/TEIID-5528
Project: Teiid
Issue Type: Feature Request
Affects Versions: 11.2
Reporter: Vojtech Kolacek
Assignee: Steven Hawkins
Insert handling of arrays is missing for PostgreSQL, e.g.
INSERT INTO "public"."form_formname" ("booltest") VALUES ((true, false, true, false))
is not being translated to
INSERT INTO "public"."form_formname" ("booltest") VALUES ('{true, false, true, false}')
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5527) show plan over pg protocol needs some thought
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5527:
-------------------------------------
Summary: show plan over pg protocol needs some thought
Key: TEIID-5527
URL: https://issues.jboss.org/browse/TEIID-5527
Project: Teiid
Issue Type: Quality Risk
Components: ODBC
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.x
Depending upon the client and the particulars of processing - simple or extended query protocol - issuing a show plan may not give the relevant plan. For example if you obtain a resultset using the jdbc client and a simple query has been issued, a show plan at the end of processing will actually show some of the under the covers metadata queries.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5526) Missing data source thorntail
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5526:
-------------------------------------
Summary: Missing data source thorntail
Key: TEIID-5526
URL: https://issues.jboss.org/browse/TEIID-5526
Project: Teiid
Issue Type: Quality Risk
Components: thorntail
Reporter: Steven Hawkins
Assignee: Steven Hawkins
If you define a vdb and there is a source for which a jndi name is not matched with a data source from the configuration, the vdb will still be deployed, but won't be active - and there is no indication in the default console log as to the progress or lack thereof with the metadata load.
Given the presumed static nature of thorntail deployments, this scenario should result in a failed deployment like embedded.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5524) Expose JMX metrics in Thorntail
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5524?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5524.
-----------------------------------
Resolution: Done
Added an initial implementation that is somewhat compatible with the admin api, but removes any vdb, domain, write, and admin api methods.
The mbeans are under org.teiid
We'll leave this undocumented for now as it may undergo refinement, such as creating actual mbeans for the engine and worker pool stats.
> Expose JMX metrics in Thorntail
> -------------------------------
>
> Key: TEIID-5524
> URL: https://issues.jboss.org/browse/TEIID-5524
> Project: Teiid
> Issue Type: Enhancement
> Components: Embedded
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0, 11.2.1
>
>
> Teiid staus and any metrics need to be exposed through JMX, such that they can be exposed later using HAWT.IO console in OpenShift. Given THORN-1918, it may be easiest to just register a few of own mbeans.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5150) JDG source model with 'v' letter at beginning of a name doesn't work.
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5150?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5150:
----------------------------------
Fix Version/s: 12.x
> JDG source model with 'v' letter at beginning of a name doesn't work.
> ---------------------------------------------------------------------
>
> Key: TEIID-5150
> URL: https://issues.jboss.org/browse/TEIID-5150
> Project: Teiid
> Issue Type: Bug
> Components: JDG Connector
> Affects Versions: 8.12.11.6_4
> Environment: Fedora 26
> Mac OS 10.12
> Reporter: Matej Kralik
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 12.x
>
> Attachments: BookMat-vdb.xml
>
>
> When the name of a JDG source model starts with 'v' letter, after run query at the materialized table (BooksMatView.viewBooks in attached VDB), the server shows exception:
> {code:java}
> 14:29:19,383 WARN [org.infinispan.client.hotrod.impl.protocol.Codec21] (Worker3_QueryProcessorQueue176) ISPN004005: Error received from the server: java.lang.IllegalArgumentException: Message descriptor not found : endorBookJDGSource.viewBooks
> 14:29:19,384 ERROR [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue176) Connector worker process failed for atomic-request=X6jNnAMTIgyp.0.6.248: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=551 returned server error (status=0x85): java.lang.IllegalArgumentException: Message descriptor not found : endorBookJDGSource.viewBooks
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:68) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:30) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:57) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.executeQuery(RemoteQuery.java:68) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.list(RemoteQuery.java:53) [infinispan-client-hotrod.jar:8.4.1.Final-redhat-2]
> at org.teiid.translator.infinispan.hotrod.InfinispanResponse.fetchNextBatch(InfinispanResponse.java:76) [translator-infinispan-hotrod-8.12.11.6_4-redhat-7.jar:8.12.11.6_4-redhat-7]
> at org.teiid.translator.infinispan.hotrod.InfinispanResponse.getNextRow(InfinispanResponse.java:92) [translator-infinispan-hotrod-8.12.11.6_4-redhat-7.jar:8.12.11.6_4-redhat-7]
> at org.teiid.translator.infinispan.hotrod.InfinispanQueryExecution.next(InfinispanQueryExecution.java:142) [translator-infinispan-hotrod-8.12.11.6_4-redhat-7.jar:8.12.11.6_4-redhat-7]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:433) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:236) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at sun.reflect.GeneratedMethodAccessor167.invoke(Unknown Source) [:1.8.0_65]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_65]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_65]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at com.sun.proxy.$Proxy42.more(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_65]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> 14:29:19,389 WARN [org.teiid.PROCESSOR] (Worker2_QueryProcessorQueue177) TEIID30020 Processing exception for request X6jNnAMTIgyp.0 'TEIID30504 vendorBookJDGSource: java.lang.IllegalArgumentException: Message descriptor not found : endorBookJDGSource.viewBooks'. Originally TeiidProcessingException Codec20.java:363. Enable more detailed logging to see the entire stacktrace.
> {code}
> JDG source model has name *vendorBookJDGSource*.
> However, the name of JDG source model in the exception doesn't contain first 'v' letter ( Message descriptor not found : *endorBookJDGSource*.viewBooks ).
> Jdg server doesn't show any exception. I use DV 6.4.0 ER3, JDG 7.1 server and JDG 7.1.1 CR2 EAP module.
> In the attachments, I upload my VDB. Remove 'v' letter fix the issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-2079) Coordinate closing continuous executions across windows and data sources
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-2079?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2079.
-----------------------------------
Resolution: Out of Date
> Coordinate closing continuous executions across windows and data sources
> ------------------------------------------------------------------------
>
> Key: TEIID-2079
> URL: https://issues.jboss.org/browse/TEIID-2079
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Mark Addleman
> Assignee: Steven Hawkins
> Priority: Major
>
> From discussion https://community.jboss.org/thread/201379?tstart=0
> In a continuous execution involving more than one data source, it is possible that one or more data sources will reach end of data with no possibility of more results. The translator API should allow for signalling this to the query engine. Further for the query engine ought to extend non-continuous end of result set processing semantics to the continuous execution case as much as possible.
> Below is a stab at what the continuous execution end of result set semantics might be.
> There are two cases: correlated results across data sources and non-correlated results.
> In the correlated case (such as an inner join), when one data source indicates end of results, the execution ends for all correlated data sources.
> In the uncorrelated case (such as a union), any data source that signals end of results is not dropped from the plan on the next window and its resources are cleaned up.
> In both cases when all data source executions end, the client should be notified through a callback mechanism.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5158) Quickstart dynamicvdb-dataroles assuming invalid user password
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5158?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5158.
-----------------------------------
Resolution: Won't Fix
This represents a product issue that can marked as won't fix on the community side.
> Quickstart dynamicvdb-dataroles assuming invalid user password
> --------------------------------------------------------------
>
> Key: TEIID-5158
> URL: https://issues.jboss.org/browse/TEIID-5158
> Project: Teiid
> Issue Type: Bug
> Components: Quick Starts
> Affects Versions: 8.12.11.6_4
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Priority: Critical
>
> dynamicvdb-dataroles
> * provide a user with which we should perform the query
> * we can't count on a user/user credentials present on server, as add-user.sh limits passwords used
> * neither portfolio/portfolio is a valid combination
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months