[JBoss JIRA] (TEIID-3747) Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3747?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3747:
-------------------------------------
As I mentioned above there are two semantics to the VDB identification
- VDB Name ( Name you gave inside the vdb.xml)
- deployment name (name of the file, like foo.vdb or foo-vdb.xml)
When Designer only using .vdb, they have control over what is being deployed, they may be successfully able to delete the old one and redeploy new one. In this case Designer is not able to recognize there is an existing VDB, thus the issue.
When a VDB is deployed using "Admin.deploy" it takes a "deployed" name, same also with "Admin.undeploy". However, when you call "Admin.getVDBs()" this will return the VDB object that contains the name of the VDB, user can call VDB.getProperty("deployment-name") that can give the "deployed" name of the vdb (in this case portfolio-vdb.xml), which can used to undeploy. I am not sure how Designer is checking, thus the issue.
> Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-3747
> URL: https://issues.jboss.org/browse/TEIID-3747
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.1.6_2
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> deployed a dynamic vdb using CLI: deploy teiidfiles/vdb/portfolio-vdb.xml
> then in Designer, tried to deploy the same named VDB, but as a .vdb and the deployment fails with errors indicating duplicate service:
> 11:26:31,301 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."Portfolio.vdb".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."Portfolio.vdb".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "Portfolio.vdb"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.teiid.ds-listener.Portfolio.1./accounts-ds is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3748) Impala translator - SELECT and HAVING statements are translating differently for Case statements
by Don Krapohl (JIRA)
Don Krapohl created TEIID-3748:
----------------------------------
Summary: Impala translator - SELECT and HAVING statements are translating differently for Case statements
Key: TEIID-3748
URL: https://issues.jboss.org/browse/TEIID-3748
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 8.11.4
Environment: Ubuntu Trusty
Reporter: Don Krapohl
Assignee: Steven Hawkins
Error from Impala-
all DISTINCT aggregate functions need to have the same set of parameters as count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE CAST(NULL AS STRING) END))
deviating function: count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE NULL END))
Query:
SELECT user_key, sum(firstcol),count(distinct case when secondcol >= 0 then 1 end)
FROM sometable
WHERE customer_key=6
GROUP BY user_key
HAVING sum(firstcol)>100
AND count(distinct case when secondcol >= 0 then 1 end)=0
Query explanation:
For all users
Add up values in the firstcol column (integer column)
count distinct values in secondcol where secondcol value zero or more
otherwise return null (output is string)
Translated Teiid query:
SELECT user_key, SUM(firstcol) as `EXPR_0`, COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE CAST(NULL AS STRING) END)) as `EXPR_1`
FROM sometable
WHERE customer_key` = 6
HAVING (EXPR_0 > 100) AND (COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE NULL END)) = 0))
Note the difference between the select and having for EXPR_1:
Select - THEN '1' ELSE CAST(NULL AS STRING) END
Having - THEN '1' ELSE NULL END
Impala doesn't accept that these are the same aggregate function. Aliases aren't accepted in the HAVING.
One further observation- if we swap the translation and write the statement in the select as
COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE NULL END*))
Teiid translates the SELECT to
COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE CAST(NULL AS STRING) END*))
So it always makes these mismatched.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3549) Join conditions with OR generate a wrong JDBC query
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3549?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3549.
---------------------------------
> Join conditions with OR generate a wrong JDBC query
> ---------------------------------------------------
>
> Key: TEIID-3549
> URL: https://issues.jboss.org/browse/TEIID-3549
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> I'm using Teiid 8.10 with h2 translator
> I have the following query containing a join with conditions separated by OR logical operator:
> select "BilanBanque"."SIGNEDDATA" as "CalculatedField1"
> from "implify_data"."Evolution_PCy_050615" "Evolution_PCy_050615"
> LEFT JOIN "implify_data"."Evolution_PCy_050615" "MidCat" ON "Evolution_PCy_050615"."ID" = "MidCat"."PID" AND ( ( ("MidCat"."Level" IN (1) ) ) )
> LEFT JOIN "implify_data"."Evolution_PCy_050615" "Data" ON ( ( ("Data"."Level" IN (2) ) ) AND ( ("Data"."PID" = "Evolution_PCy_050615"."ID") OR ("Data"."PID" = "MidCat"."ID") ) )
> LEFT JOIN "implify_data"."Sheet1_haU_010615" "BilanBanque" ON "Data"."ID" = "BilanBanque"."Account"
> where ("BilanBanque"."BankName" IN ('Bank1') )
> The corresponding JDBC query executed by Teiid contains 2 times ON after the join:
> SELECT g_3."SIGNEDDATA" FROM "implify_data"."Evolution_PCy_050615" AS g_0 LEFT OUTER JOIN "implify_data"."Evolution_PCy_050615" AS g_1 ON g_0."ID" = g_1."PID" AND g_1."Level" = 1 INNER JOIN "implify_data"."Evolution_PCy_050615" AS g_2 INNER JOIN "implify_data"."Sheet1_haU_010615" AS g_3 ON g_2."ID" = g_3."Account" ON g_2."PID" = g_0."ID" OR g_2."PID" = g_1."ID" WHERE g_2."Level" = 2 AND g_3."BankName" = 'Bank1'
> if I remove the conditions with OR from the join, the query executes with success.
> You find below the execution plan:
> <?xml version='1.0' encoding='UTF-8'?><node name="AccessNode"><property name="Relational Node ID"><value>0</value></property><property name="Output Columns"><value>CalculatedField1 (bigdecimal)</value></property><property name="Statistics"><value>Node Output Rows: 0</value><value>Node Next Batch Process Time: 0</value><value>Node Cumulative Next Batch Process Time: 16</value><value>Node Cumulative Process Time: 0</value><value>Node Next Batch Calls: 1</value><value>Node Blocks: 1</value></property><property name="Cost Estimates"><value>Estimated Node Cardinality: -1.0</value></property><property name="Query"><value>SELECT g_3.SIGNEDDATA FROM (implify_dataModel.implify_data.Evolution_PCy_050615 AS g_0 LEFT OUTER JOIN implify_dataModel.implify_data.Evolution_PCy_050615 AS g_1 ON g_0.ID = g_1.PID AND g_1.Level = 1) INNER JOIN (implify_dataModel.implify_data.Evolution_PCy_050615 AS g_2 INNER JOIN implify_dataModel.implify_data.Sheet1_haU_010615 AS g_3 ON g_2.ID = g_3.Account) ON ((g_2.PID = g_0.ID) OR (g_2.PID = g_1.ID)) WHERE (g_2.Level = 2) AND (g_3.BankName = 'Bank1')</value></property><property name="Model Name"><value>implify_dataModel</value></property><property name="Data Bytes Sent"><value>0</value></property></node>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3552) NPE on calling the native query procedure with null variable parameter
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3552?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3552.
---------------------------------
> NPE on calling the native query procedure with null variable parameter
> ----------------------------------------------------------------------
>
> Key: TEIID-3552
> URL: https://issues.jboss.org/browse/TEIID-3552
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> Calling the native query procedure and passing null as "variable" parameter like in the following example:
> {code:sql}
> exec my.native("request" => 'Select 1', "variable" => null)
> {code}
> the following exception is thrown:
> {code:sql}
> 19:41:00,707 ERROR [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue10) zC4UryNl1/3R TEIID30019 Unexpected exception for request zC4UryNl1/3R.5: java.lang.NullPointerException
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:958) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:183) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.<init>(ConnectorWorkItem.java:165) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.datamgr.ConnectorManager.registerRequest(ConnectorManager.java:203) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.process.DataTierManagerImpl.registerRequest(DataTierManagerImpl.java:966) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:179) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.relational.AccessNode.registerRequest(AccessNode.java:475) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.relational.AccessNode.open(AccessNode.java:248) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.open(RelationalNode.java:254) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.relational.RelationalPlan.open(RelationalPlan.java:136) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:231) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.11.0.Final.jar:8.11.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
> {code}
> As a workaround, the query is successfully executed if the "variable" parameter is omitted:
> {code:sql}
> exec my.native("request" => 'Select 1')
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3204) Admin shell throws an IncompatibleClassChangeError
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3204?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3204.
---------------------------------
> Admin shell throws an IncompatibleClassChangeError
> --------------------------------------------------
>
> Key: TEIID-3204
> URL: https://issues.jboss.org/browse/TEIID-3204
> Project: Teiid
> Issue Type: Bug
> Components: Tools
> Affects Versions: 8.7.1
> Environment: OS: fedora 20
> arch: x86_64
> java: oracle 1.7
> Reporter: Juraj Duráni
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2
>
>
> Admin shell throws an IncompatibleClassChangeError when wrong path to groovy script is provided along with load command.
> Actual result:
> ===> [import static org.teiid.adminshell.AdminShell.*; import static org.teiid.adminshell.GroovySqlExtensions.*; import org.teiid.adminapi.*;]
> FATAL: java.lang.IncompatibleClassChangeError: the number of constructors during runtime and compile time for java.lang.Exception do not match. Expected 4 but got 5
> java.lang.IncompatibleClassChangeError: the number of constructors during runtime and compile time for java.lang.Exception do not match. Expected 4 but got 5
> at groovy.lang.MetaClassImpl.selectConstructorAndTransformArguments(MetaClassImpl.java:1406)
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.selectConstructorAndTransformArguments(ScriptBytecodeAdapter.java:237)
> at org.codehaus.groovy.tools.shell.CommandException.<init>(Command.groovy:60)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> ....
> ....
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3437) Inconsistencies with row count handling
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3437?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3437.
---------------------------------
> Inconsistencies with row count handling
> ---------------------------------------
>
> Key: TEIID-3437
> URL: https://issues.jboss.org/browse/TEIID-3437
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors, Query Engine
> Affects Versions: 8.10
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.10.1, 8.11, 8.7.3
>
>
> With TEIID-3271 we addressed returning all of the update counts from a bulk operation such that the direct JDBC logic was correct. However this left the logic inconsistent with the projectintonode (which could result in invalid rowcount variables) and with the accumulo, solr, and simpledb translators.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3504) Null pointer exception executing dynamic sql
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3504?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3504.
---------------------------------
> Null pointer exception executing dynamic sql
> --------------------------------------------
>
> Key: TEIID-3504
> URL: https://issues.jboss.org/browse/TEIID-3504
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.11
>
>
> When a procedure with dynamic sql is rerun the cloning of the group context allows for the same linked list to be modified by multiple threads leading to errors, which typically resemble a null pointer exception (for example at QueryResolver line 259 due to a null group). The cloning also allows for the group context groups to grow in number as the locally scoped groups are re-added.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months