[JBoss JIRA] (TEIID-4742) Provide query prioritization feature
by Van Halbert (JIRA)
Van Halbert created TEIID-4742:
----------------------------------
Summary: Provide query prioritization feature
Key: TEIID-4742
URL: https://issues.jboss.org/browse/TEIID-4742
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Reporter: Van Halbert
Assignee: Steven Hawkins
as the system’s utilization surges, query prioritization, queuing and resource scaling will dynamically manage the added load without degrading or crashing the system or impacting essential / critical mission operations
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4717) Add Support for 'ALLOW FILTERING' in Teiid Cassandra Translator
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4717?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4717:
-------------------------------------
>From the blog you shared about ALLOW FILTERING, essentially Teiid will do the same when column is set to not searchable. It will get all the table contents and then filter out not non matching criteria. So, I am no seeing any downside to use ALLOW FILTERING. The question is do you want to do this on all the columns of table or just some specific ones? IMO doing on all of them is fine as that would be default behavior anyway if you not defined the property ALLOW FILTERING. Then question becomes, why not do this by default on all tables? i.e. always tack on ALLOW FILTERING to query?
> Add Support for 'ALLOW FILTERING' in Teiid Cassandra Translator
> ---------------------------------------------------------------
>
> Key: TEIID-4717
> URL: https://issues.jboss.org/browse/TEIID-4717
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Reporter: Vijay K
> Labels: cassandra
> Fix For: 9.3
>
>
> At certain times it is unavoidable to use few columns in the where clause which are not part of the index, in that case Cassandra driver throws error
> {color:red}Bad Request: Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING{color}
> As a user I should be able to configure the Cassandra translator to append *ALLOW FILTERING* to the generated query (CQL)
> References:
> https://www.datastax.com/dev/blog/allow-filtering-explained-2
> https://developer.jboss.org/thread/239011
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4740) Update statement doesn't work correctly for data sources in some cases
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4740?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4740:
---------------------------------------
How would you push this down across the databases?
If there is no key, then you can't do row by row updates. It seems that you would have to take some other approach like creating an analogous temporary table on the test source to process the update. In any case that is a new feature.
> Update statement doesn't work correctly for data sources in some cases
> ----------------------------------------------------------------------
>
> Key: TEIID-4740
> URL: https://issues.jboss.org/browse/TEIID-4740
> 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
>
> Running the following query:
> {code:sql}
> UPDATE test_int.contacttest
> SET test_int.contacttest.salutation = (
> select
> test_int.updatetest.prefix
> from test_int.updatetest
> where test_int.updatetest.id = test_int.contacttest.id
> );
> {code}
> works correctly changing salutation field value according to where condition (note that contacttest and updatetest table are in the same test_int data source). But the following query:
> {code:sql}
> UPDATE test.contacttest
> SET test.contacttest.salutation = (
> select
> test_int.updatetest.prefix
> from test_int.updatetest
> where test_int.updatetest.id = test.contacttest.id
> );
> {code}
> will fail as we try to update "contacttest" table of "test" data source from another "test_int" data source using "updatetest" table in where condition. The query fails showing the following error message:
> {code}
> Error: TEIID30253 Remote org.teiid.api.exception.query.QueryPlannerException: TEIID30253 Source UPDATE or DELETE command "UPDATE test.contacttest SET salutation = (SELECT test_int.updatetest.prefix FROM test_int.updatetest WHERE test_int.updatetest.id = test.contacttest.id LIMIT 2)" contains non-pushdown constructs and no compensating action can be taken as the table lacks a unique key or the source does not support equality predicates.
> SQLState: 50000
> ErrorCode: 30253
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4741) After VDB undeploy (due to VDB syntax errors), system throws several TeiidProcessingException Warnings
by Pedro Inácio (JIRA)
[ https://issues.jboss.org/browse/TEIID-4741?page=com.atlassian.jira.plugin... ]
Pedro Inácio updated TEIID-4741:
--------------------------------
Attachment: server.log
> After VDB undeploy (due to VDB syntax errors), system throws several TeiidProcessingException Warnings
> ------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4741
> URL: https://issues.jboss.org/browse/TEIID-4741
> Project: Teiid
> Issue Type: Bug
> Components: Common
> Environment: * Teiid 9.1.2
> * WildFly 10
> Reporter: Pedro Inácio
> Assignee: Steven Hawkins
> Fix For: 9.1.2
>
> Attachments: server.log
>
>
> After re-deploying a *VDB *(with a syntax errors this time), the system throws several warnings (until the server is stopped) related to the undeployed VDB.
> The errors are of type:
> _Caused by: org.teiid.core.TeiidProcessingException: TEIID31099 VDB ..._
> This should not be happening, since the VDB was undeployed.
> To be notice that the VDB has External Materialization.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4741) After VDB undeploy (due to VDB syntax errors), system throws several TeiidProcessingException Warnings
by Pedro Inácio (JIRA)
Pedro Inácio created TEIID-4741:
-----------------------------------
Summary: After VDB undeploy (due to VDB syntax errors), system throws several TeiidProcessingException Warnings
Key: TEIID-4741
URL: https://issues.jboss.org/browse/TEIID-4741
Project: Teiid
Issue Type: Bug
Components: Common
Environment: * Teiid 9.1.2
* WildFly 10
Reporter: Pedro Inácio
Assignee: Steven Hawkins
Fix For: 9.1.2
Attachments: server.log
After re-deploying a *VDB *(with a syntax errors this time), the system throws several warnings (until the server is stopped) related to the undeployed VDB.
The errors are of type:
_Caused by: org.teiid.core.TeiidProcessingException: TEIID31099 VDB ..._
This should not be happening, since the VDB was undeployed.
To be notice that the VDB has External Materialization.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4682) PrestoDB translator - cannot use temp tables - PrestoDB could not commit transaction
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4682?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4682.
-----------------------------------
Resolution: Done
Marking as resolved with the documentation updates.
> PrestoDB translator - cannot use temp tables - PrestoDB could not commit transaction
> ------------------------------------------------------------------------------------
>
> Key: TEIID-4682
> URL: https://issues.jboss.org/browse/TEIID-4682
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.8.6_3
> Reporter: Juraj Duráni
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Teiid cannot properly insert data into temp table from PrestoDB tables. Teiid seems to try commit transaction on PrestoDB connection which is in auto-commit mode. Data are pulled from the PrestoDB, but operation fails on closing the processor.
> Query \[1\], log \[2\].
> {code:sql|title=\[1\]}
> INSERT INTO #t SELECT IntKey FROM Bqt1.Smalla
> {code}
> {code:plain|title=\[2\]}
> 4:29:14,758 DEBUG [org.teiid.TRANSPORT] (New I/O worker #3) processing message:MessageHolder: key=248 contents=Invoke interface org.teiid.client.DQP.executeRequest
> 14:29:14,763 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) Request Thread A7WqBzZhsyYM.47 with state NEW
> 14:29:14,763 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47 Command has no cache hint and result set cache mode is not on.
> 14:29:14,763 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47 executing INSERT INTO #t SELECT IntKey FROM Bqt1.Smalla
> 14:29:14,768 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) ProcessTree for A7WqBzZhsyYM.47 ProjectIntoNode(0) output=[Count] #t
> AccessNode(1) output=[IntKey] SELECT g_0.IntKey FROM Source.SmallA AS g_0
> 14:29:14,768 DEBUG [org.teiid.TXN_LOG] (Worker26_QueryProcessorQueue135) before getOrCreateTransactionContext:org.teiid.dqp.internal.process.TransactionServerImpl@168af7b8(A7WqBzZhsyYM)
> 14:29:14,769 DEBUG [org.teiid.TXN_LOG] (Worker26_QueryProcessorQueue135) after getOrCreateTransactionContext : A7WqBzZhsyYM NONE ID:NONE
> 14:29:14,769 DEBUG [org.teiid.TXN_LOG] (Worker26_QueryProcessorQueue135) before begin:org.teiid.dqp.internal.process.TransactionServerImpl@168af7b8(A7WqBzZhsyYM NONE ID:NONE)
> 14:29:14,769 DEBUG [org.teiid.TXN_LOG] (Worker26_QueryProcessorQueue135) after begin : null
> 14:29:14,769 DEBUG [org.teiid.BUFFER_MGR] (Worker26_QueryProcessorQueue135) Creating TupleBuffer: 71 [Count] [class java.lang.Integer] batch size 2048 of type PROCESSOR
> 14:29:14,769 DEBUG [org.teiid.TXN_LOG] (Worker26_QueryProcessorQueue135) before resume:org.teiid.dqp.internal.process.TransactionServerImpl@168af7b8(A7WqBzZhsyYM REQUEST ID:TransactionImple < ac, BasicAction: 0:ffff0a2804a3:-d43e932:586f78d7:23a status: ActionStatus.RUNNING >)
> 14:29:14,769 DEBUG [org.teiid.TXN_LOG] (Worker26_QueryProcessorQueue135) after resume : null
> 14:29:14,769 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Create State
> 14:29:14,770 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Processing NEW request: SELECT g_0.IntKey FROM Source.SmallA AS g_0
> 14:29:15,290 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Obtained execution
> 14:29:15,290 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) Source-specific command: SELECT g_0.intkey FROM smalla AS g_0
> 14:29:15,613 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Executed command
> 14:29:15,614 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Processing MORE request
> 14:29:15,614 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Getting results from connector
> 14:29:15,772 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Obtained last batch, total row count: 50
> 14:29:15,772 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Remove State
> 14:29:15,772 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Processing Close : SELECT g_0.IntKey FROM Source.SmallA AS g_0
> 14:29:15,773 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Closed execution
> 14:29:15,773 DEBUG [org.teiid.CONNECTOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47.1.31 Closed connection
> 14:29:15,773 DEBUG [org.teiid.BUFFER_MGR] (Worker26_QueryProcessorQueue135) Creating TupleBuffer: 72 [#t.IntKey] [class java.lang.Integer] batch size 2048 of type PROCESSOR
> 14:29:15,773 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) Creating temporary table #t
> 14:29:15,774 DEBUG [org.teiid.BUFFER_MGR] (Worker26_QueryProcessorQueue135) Creating STree: 73
> 14:29:15,774 DEBUG [org.teiid.BUFFER_MGR] (Worker26_QueryProcessorQueue135) Creating TupleBuffer: 75 [rowId, #t.IntKey] [class java.lang.Integer, class java.lang.Integer] batch size 2048 of type PROCESSOR
> 14:29:15,774 DEBUG [org.teiid.BUFFER_MGR] (Worker26_QueryProcessorQueue135) Removing TupleBuffer: 72
> 14:29:15,774 DEBUG [org.teiid.BUFFER_MGR] (Worker26_QueryProcessorQueue135) Removing TupleBuffer: 75
> 14:29:15,775 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) QueryProcessor: closing processor
> 14:29:15,775 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) A7WqBzZhsyYM.47 Finished Processing
> 14:29:15,775 DEBUG [org.teiid.TXN_LOG] (Worker26_QueryProcessorQueue135) before commit:org.teiid.dqp.internal.process.TransactionServerImpl@168af7b8(A7WqBzZhsyYM REQUEST ID:TransactionImple < ac, BasicAction: 0:ffff0a2804a3:-d43e932:586f78d7:23a status: ActionStatus.RUNNING >)
> 14:29:15,775 WARN [com.arjuna.ats.jta] (Worker26_QueryProcessorQueue135) ARJUNA016039: onePhaseCommit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a2804a3:-d43e932:586f78d7:23a, node_name=1, branch_uid=0:ffff0a2804a3:-d43e932:586f78d7:23d, subordinatenodename=null, eis_name=java:/PrestoDB > (LocalXAResourceImpl@1e4cfe92[connectionListener=1a737904 connectionManager=4bd5154a warned=false currentXid=null productName=Presto productVersion=0.161 jndiName=java:/PrestoDB]) failed with exception XAException.XA_RBROLLBACK: org.jboss.jca.core.spi.transaction.local.LocalXAException: IJ001156: Could not commit local transaction
> at org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.commit(LocalXAResourceImpl.java:176) [ironjacamar-core-impl-1.0.37.Final-redhat-1.jar:1.0.37.Final-redhat-1]
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.commit(XAOnePhaseResource.java:120)
> at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelPrepare(LastResourceRecord.java:152)
> at com.arjuna.ats.arjuna.coordinator.AbstractRecord.topLevelOnePhaseCommit(AbstractRecord.java:423)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2287)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1488)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1211)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.teiid.dqp.internal.process.TransactionServerImpl.commitDirect(TransactionServerImpl.java:411) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.TransactionServerImpl.commit(TransactionServerImpl.java:542) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_92]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_92]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_92]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_92]
> at org.teiid.logging.LogManager$LoggingProxy.invoke(LogManager.java:121) [teiid-api-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at com.sun.proxy.$Proxy19.commit(Unknown Source)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:494) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_92]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.resource.ResourceException: SQLException
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.checkException(BaseWrapperManagedConnection.java:1198)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.commit(LocalManagedConnection.java:107)
> at org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.commit(LocalXAResourceImpl.java:171) [ironjacamar-core-impl-1.0.37.Final-redhat-1.jar:1.0.37.Final-redhat-1]
> ... 28 more
> Caused by: java.sql.SQLException: Connection is in auto-commit mode
> at com.facebook.presto.jdbc.PrestoConnection.commit(PrestoConnection.java:144)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.commit(LocalManagedConnection.java:96)
> ... 29 more
> 14:29:15,780 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) Rolling back txn TransactionImple < ac, BasicAction: 0:ffff0a2804a3:-d43e932:586f78d7:23a status: ActionStatus.RUNNING > restoring [] using rollback tables {}
> 14:29:15,780 WARN [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) TEIID30020 Processing exception for request A7WqBzZhsyYM.47 'TEIID30530 javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.'. Originally XATransactionException TransactionImple.java:1223.: org.teiid.client.xa.XATransactionException: TEIID30530 javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
> at org.teiid.dqp.internal.process.TransactionServerImpl.commitDirect(TransactionServerImpl.java:415) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.TransactionServerImpl.commit(TransactionServerImpl.java:542) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_92]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_92]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_92]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_92]
> at org.teiid.logging.LogManager$LoggingProxy.invoke(LogManager.java:121) [teiid-api-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at com.sun.proxy.$Proxy19.commit(Unknown Source)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:494) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_92]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1223)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.teiid.dqp.internal.process.TransactionServerImpl.commitDirect(TransactionServerImpl.java:411) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> ... 17 more
> 14:29:15,781 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) Removing tuplesource for the request A7WqBzZhsyYM.47
> 14:29:15,781 DEBUG [org.teiid.BUFFER_MGR] (Worker26_QueryProcessorQueue135) Removing TupleBuffer: 71
> 14:29:15,781 DEBUG [org.teiid.PROCESSOR] (Worker26_QueryProcessorQueue135) org.teiid.client.xa.XATransactionException: TEIID30530 javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. Sending error to client A7WqBzZhsyYM.47
> 14:29:15,782 DEBUG [org.teiid.TRANSPORT] (Worker26_QueryProcessorQueue135) send message: MessageHolder: key=248 contents=ResultsMessage rowCount=0 finalRow=-1
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4740) Update statement doesn't work correctly for data sources in some cases
by dalex dalex (JIRA)
[ https://issues.jboss.org/browse/TEIID-4740?page=com.atlassian.jira.plugin... ]
dalex dalex commented on TEIID-4740:
------------------------------------
[~shawkins] can't it really be pushed down? Just wondering because such update works within one data source but doesn't work with two data sources within one DB. On MySQL, of course, both queries work.
> Update statement doesn't work correctly for data sources in some cases
> ----------------------------------------------------------------------
>
> Key: TEIID-4740
> URL: https://issues.jboss.org/browse/TEIID-4740
> 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
>
> Running the following query:
> {code:sql}
> UPDATE test_int.contacttest
> SET test_int.contacttest.salutation = (
> select
> test_int.updatetest.prefix
> from test_int.updatetest
> where test_int.updatetest.id = test_int.contacttest.id
> );
> {code}
> works correctly changing salutation field value according to where condition (note that contacttest and updatetest table are in the same test_int data source). But the following query:
> {code:sql}
> UPDATE test.contacttest
> SET test.contacttest.salutation = (
> select
> test_int.updatetest.prefix
> from test_int.updatetest
> where test_int.updatetest.id = test.contacttest.id
> );
> {code}
> will fail as we try to update "contacttest" table of "test" data source from another "test_int" data source using "updatetest" table in where condition. The query fails showing the following error message:
> {code}
> Error: TEIID30253 Remote org.teiid.api.exception.query.QueryPlannerException: TEIID30253 Source UPDATE or DELETE command "UPDATE test.contacttest SET salutation = (SELECT test_int.updatetest.prefix FROM test_int.updatetest WHERE test_int.updatetest.id = test.contacttest.id LIMIT 2)" contains non-pushdown constructs and no compensating action can be taken as the table lacks a unique key or the source does not support equality predicates.
> SQLState: 50000
> ErrorCode: 30253
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4737) Incorrect work of left join statement
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4737?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4737.
-----------------------------------
Fix Version/s: 9.1.4
9.0.6
9.2
Resolution: Done
Corrected the logic to not perform the view removal in outer join cases.
> Incorrect work of left join statement
> -------------------------------------
>
> Key: TEIID-4737
> URL: https://issues.jboss.org/browse/TEIID-4737
> 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
> Fix For: 9.1.4, 9.0.6, 9.2
>
> Attachments: test_emails_bug1.jpg, test_emails_pg.jpg
>
>
> the following query:
> {code:sql}
> SELECT a.email, b.email, lower(a.email), lower(b.email) FROM test_tables.test_emails as a left join views.test_view_emails as b on lower(a.email)=lower(b.email)
> {code}
> leads to the following results:
> !test_emails_bug1.jpg|thumbnail!
> though running the same query on PostgreSQL leads to the following results:
> !test_emails_pg.jpg|thumbnail!
> so this query mentioned above must work as on PostgreSQL putting null values for the b field table where conditions can't be performed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4740) Update statement doesn't work correctly for data sources in some cases
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4740?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4740:
---------------------------------------
This is not a correctness issue. If you issue an update with a predicate that cannot be pushed we can compensate for that by creating a "for each row" plan to perform the modification off of select. However that is only possible if the rows can be uniquely identified. This will need to be rejected unless there is something else you see going on here.
> Update statement doesn't work correctly for data sources in some cases
> ----------------------------------------------------------------------
>
> Key: TEIID-4740
> URL: https://issues.jboss.org/browse/TEIID-4740
> 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
>
> Running the following query:
> {code:sql}
> UPDATE test_int.contacttest
> SET test_int.contacttest.salutation = (
> select
> test_int.updatetest.prefix
> from test_int.updatetest
> where test_int.updatetest.id = test_int.contacttest.id
> );
> {code}
> works correctly changing salutation field value according to where condition (note that contacttest and updatetest table are in the same test_int data source). But the following query:
> {code:sql}
> UPDATE test.contacttest
> SET test.contacttest.salutation = (
> select
> test_int.updatetest.prefix
> from test_int.updatetest
> where test_int.updatetest.id = test.contacttest.id
> );
> {code}
> will fail as we try to update "contacttest" table of "test" data source from another "test_int" data source using "updatetest" table in where condition. The query fails showing the following error message:
> {code}
> Error: TEIID30253 Remote org.teiid.api.exception.query.QueryPlannerException: TEIID30253 Source UPDATE or DELETE command "UPDATE test.contacttest SET salutation = (SELECT test_int.updatetest.prefix FROM test_int.updatetest WHERE test_int.updatetest.id = test.contacttest.id LIMIT 2)" contains non-pushdown constructs and no compensating action can be taken as the table lacks a unique key or the source does not support equality predicates.
> SQLState: 50000
> ErrorCode: 30253
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4730) Problem with Import VDB with Materialized View (external)
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4730?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4730:
---------------------------------------
> So, let's redo on those terms
Yes, that is what I'm trying to do. That's why I'm avoiding using the old terms as they conceptually don't work well.
> Obviously my patch was to ignore scoping in import case (X.2) and follow SCHEMA scope all the way, Now how does this need to map to none, shared, fully-shared strategy?
To clarify the issues as I see them:
||Scope||X.1||Y.1||X.2||Comment||
|None|A-own|C-own|A-own,B-own,C-own|Not fully implemented|
|VDB|A-own|C-own|A-Shared from/ X.1,B-own,C-own|Does not make sense from a user perspective to share across versions, but not importing. Also not fully implemented as multiple entries for the same materialization can be created in the status table|
|SCHEMA|A-own|C-own|A-Shared from/ X.1,B-own,C-Shared from/Y.1|Breaks vdb encapsulation and also not fully implemented as multiple entries for the same materialization can be created in the status table|
So instead I'm proposing:
- to fully implement NONE or if we see that as a corner case for now, then to not offer that feature.
- schema sharing maps to "fully shared" - but it would be implemented so that it is vdb encapsulated and there is only 1 materialized table entry in the status table.
- shared by name/version doesn't quite conceptually match up to VDB sharing, but it addresses the deficiency with VDB sharing when importing
> Problem with Import VDB with Materialized View (external)
> ---------------------------------------------------------
>
> Key: TEIID-4730
> URL: https://issues.jboss.org/browse/TEIID-4730
> Project: Teiid
> Issue Type: Bug
> Components: Common
> Affects Versions: 9.1.2
> Environment: * Teiid 9.1.2
> * CentOs 7
> * WildFly 10
> Reporter: Pedro Inácio
> Assignee: Ramesh Reddy
> Labels: CR1
> Fix For: 9.2
>
> Attachments: externalMaterializationOrderProblem-vdb.xml, numberingPlan-vdb.xml
>
>
> Having defined a VDB which contains a Model that has External Materialization, when importing this VDB into another that also uses External Materialization, Teiid Server is searching in the wrong place for the view status.
> Example:
> ..
> <import-vdb name="CountryServiceListVDB" version="1" import-data-policies="true"/>
> ...
> <model name="MyView" type="VIRTUAL">
> ...
> SELECT cns,
> country_code
> FROM NumberingPlan.numbering_plan;
> ....
> </metadata>
> </model>
> *NumberingPlan.numbering_plan is defined in the imported VDB, and is also Materialized.*
> *Warning in Logs: *
> 17:51:45,161 WARN [org.teiid.MATVIEWS] (Worker8_QueryProcessorQueue10653) n9M6de3y5xHM org.teiid.jdbc.TeiidSQLException: TEIID30328 Unable to evaluate (SELECT mvstatus('NumberingPlan', 'numbering_plan', Valid, LoadState, 'THROW_EXCEPTION') FROM (SELECT 1) AS x LEFT OUTER JOIN NumberingPlanMaterialized.status ON VDBName = 'ExternalMaterializationOrderProblem' AND VDBVersion = '1' AND SchemaName = 'NumberingPlan' AND Name = 'numbering_plan' LIMIT 2): TEIID30328 Unable to evaluate mvstatus('NumberingPlan', 'numbering_plan', Valid, LoadState, 'THROW_EXCEPTION'): TEIID30384 Error while evaluating function mvstatus
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months