[JBoss JIRA] (TEIID-2605) Optimization substitutes wrong column in where clause
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2605?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2605.
---------------------------------
> Optimization substitutes wrong column in where clause
> -----------------------------------------------------
>
> Key: TEIID-2605
> URL: https://issues.jboss.org/browse/TEIID-2605
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1
> Environment: z/OS
> Reporter: Jeff Hayes
> Assignee: Steven Hawkins
> Attachments: query_plan.txt, views.xml
>
>
> Optimization results in a query with a different column in the WHERE clause producing an empty result set.
> Full query plan is attached but the beginning and ending queries are shown below. Note that the subject column of the IN clause is SCOPEID but optimization changes it to AUTHID for some reason.
> USER COMMAND:
> SELECT * FROM SECURITY.SCPXREF AS CHORUS_B WHERE (CHORUS_B.SYSID = 'DE29') AND ((CHORUS_B.SCOPEID IN (SELECT SN5.SCOPEID FROM SECURI
> TY.SCPNEXT AS SN5 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN4.SCOPEID FROM SECURITY.SCPNEXT AS SN4 WHERE (SYSID = 'DE29') AND
> (NEXTREC IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURI
> TY.SCPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))))))) OR (CHORUS_B.SCOPEID IN (SELECT SN4.SCOPEID FROM SECURIT
> Y.SCPNEXT AS SN4 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND
> (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURITY.SCPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))))) OR (CHORUS_B.SC
> OPEID IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURITY.S
> CPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))) OR (CHORUS_B.SCOPEID IN (SELECT SN2.SCOPEID FROM SECURITY.SCPNEX
> T AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))) OR (CHORUS_B.SCOPEID = 'CHRDEPT1'))
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> AccessNode(10) output=[x.sysid AS sysid, x.scopeid AS authid, x.authid AS scopeid, x.authtype AS authtype] SELECT g_0.SYSID, g_0.SCO
> PEID, g_0.AUTHID, g_0.AUTHTYPE FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPXREF AS g_0 WHERE (g_0.SYSID = 'DE29') AND ((g_0.AUTHID IN
> (SELECT g_1.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_1 WHERE (g_1.SYSID = 'DE29') AND (g_1.NEXTREC IN (SELECT g_2
> .SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_2 WHERE (g_2.SYSID = 'DE29') AND (g_2.NEXTREC IN (SELECT g_3.SCOPEID FR
> OM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_3 WHERE (g_3.SYSID = 'DE29') AND (g_3.NEXTREC IN (SELECT g_4.SCOPEID FROM SECURITY
> _CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_4 WHERE (g_4.SYSID = 'DE29') AND (g_4.NEXTREC = 'CHRDEPT1'))))))))) OR (g_0.AUTHID IN (SELECT
> g_5.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_5 WHERE (g_5.SYSID = 'DE29') AND (g_5.NEXTREC IN (SELECT g_6.SCOPEI
> D FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_6 WHERE (g_6.SYSID = 'DE29') AND (g_6.NEXTREC IN (SELECT g_7.SCOPEID FROM SECU
> RITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_7 WHERE (g_7.SYSID = 'DE29') AND (g_7.NEXTREC = 'CHRDEPT1'))))))) OR (g_0.AUTHID IN (SELE
> CT g_8.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_8 WHERE (g_8.SYSID = 'DE29') AND (g_8.NEXTREC IN (SELECT g_9.SCOP
> EID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_9 WHERE (g_9.SYSID = 'DE29') AND (g_9.NEXTREC = 'CHRDEPT1'))))) OR (g_0.AUTH
> ID IN (SELECT g_10.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_10 WHERE (g_10.SYSID = 'DE29') AND (g_10.NEXTREC = 'C
> HRDEPT1'))) OR (g_0.AUTHID = 'CHRDEPT1'))
> The view definitions are shown below:
> <view name="SCPNEXT">
> <columns>
> <column name="sysid" type="varchar"/>
> <column name="scopeid" type="varchar"/>
> <column name="nextrec" type="varchar"/>
> </columns>
> <definition>
> #if ($db.count("select count(*) from sys.tables where Name='config' and SchemaName = 'security_db'") > 0)
> #set ($count = 0)
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> #if ($db.count("select count(*) from sys.tables where SchemaName = 'SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}'") == 0)
> #set ($count = $count + 1)
> #end
> #end
> #if ($count == 0)
> SELECT t.sysid, t.scopeid, t.nextrec
> FROM (
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> SELECT n.sysid, n.scopeid, n.nextrec
> FROM SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}.SCPNEXT n
> #if( $velocityHasNext ) UNION #end
> #end
> ) AS t
> #end
> #end
> </definition>
> </view>
> <view name="SCPXREF">
> <columns>
> <column name="sysid" type="varchar"/>
> <column name="authid" type="varchar"/>
> <column name="scopeid" type="varchar"/>
> <column name="authtype" type="varchar"/>
> </columns>
> <definition>
> #if ($db.count("select count(*) from sys.tables where Name='config' and SchemaName = 'security_db'") > 0)
> #set ($count = 0)
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> #if ($db.count("select count(*) from sys.tables where SchemaName = 'SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}'") == 0)
> #set ($count = $count + 1)
> #end
> #end
> #if ($count == 0)
> SELECT sysid, scopeid, authid, authtype
> FROM (
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> SELECT x.sysid, x.scopeid, x.authid, x.authtype
> FROM SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}.SCPXREF x
> #if( $velocityHasNext ) UNION #end
> #end
> ) AS t
> #end
> #end
> </definition>
> </view>
> I guess the best way to test this is to define these views and run the input query with SHOWPLAN=DEBUG and see if the AUTHID substitution is occurring.
> Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
1 month, 2 weeks
[JBoss JIRA] (TEIIDSB-170) Automate materialization to JDG
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIIDSB-170:
---------------------------------
Story Points: 4
> Automate materialization to JDG
> -------------------------------
>
> Key: TEIIDSB-170
> URL: https://issues.redhat.com/browse/TEIIDSB-170
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Components: OpenShift
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 1.4.0
>
>
> Create an internal materialization replacement needs that is turnkey materialization to JDG (little to no user setup required)
> - the operator may create the infinispan cluster if needed
> - the status table and internal representation of the materialization target would be setup automatically
> For the user this would be as simple marking a view as materialized and then it would be populated in jdg upon deployment. They would not have any concerns with cache naming, status tables, etc.
> For simplicity the initial version would make a similar assumption to the current internal logic - it is for only a specific vdb. If the vdb cr is modified, then it's expected that the cache would be recreated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5798) Mixed PERMISSION GRANTS
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5798?focusedWorklogId=12450349&pag... ]
Steven Hawkins logged work on TEIID-5798:
-----------------------------------------
Author: Steven Hawkins
Created on: 28/Feb/20 3:45 PM
Start Date: 28/Feb/20 3:44 PM
Worklog Time Spent: 2 hours, 30 minutes
Work Description: for doc updates and second commit for migration
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 2 hours)
Time Spent: 2 days, 2 hours, 30 minutes (was: 2 days)
Worklog Id: (was: 12450349)
> Mixed PERMISSION GRANTS
> -----------------------
>
> Key: TEIID-5798
> URL: https://issues.redhat.com/browse/TEIID-5798
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Original Estimate: 6 hours
> Time Spent: 2 days, 2 hours, 30 minutes
> Remaining Estimate: 0 minutes
>
> Hello,
> I am currently trying to set a set of permissions on a table/view. Hence a condition on INSERT,UPDATE,DELETE and an unconditioned SELECT.
> However, it seems that conditioned and unconditioned GRANT statements do not work together.
> {code}
> GRANT INSERT,UPDATE,DELETE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" CONDITION 'UserDefinedProducts_SRC.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36) )' TO odata;
> GRANT SELECT ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" TO odata;
> REVOKE ALTER,EXECUTE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" FROM odata;
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5798) Mixed PERMISSION GRANTS
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5798?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIID-5798:
---------------------------------------
Added another commit that will write ddl out with policies instead of grants with conditions. It does not seem like a good idea to do this inline as we have odd side effects. This will serve as the migration mechanism.
> Mixed PERMISSION GRANTS
> -----------------------
>
> Key: TEIID-5798
> URL: https://issues.redhat.com/browse/TEIID-5798
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Original Estimate: 6 hours
> Time Spent: 2 days
> Remaining Estimate: 2 hours
>
> Hello,
> I am currently trying to set a set of permissions on a table/view. Hence a condition on INSERT,UPDATE,DELETE and an unconditioned SELECT.
> However, it seems that conditioned and unconditioned GRANT statements do not work together.
> {code}
> GRANT INSERT,UPDATE,DELETE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" CONDITION 'UserDefinedProducts_SRC.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36) )' TO odata;
> GRANT SELECT ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" TO odata;
> REVOKE ALTER,EXECUTE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" FROM odata;
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5908) Issue with "timestamp with timezone" redshift data type
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5908?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5908:
----------------------------------
Fix Version/s: 13.x
> Issue with "timestamp with timezone" redshift data type
> -------------------------------------------------------
>
> Key: TEIID-5908
> URL: https://issues.redhat.com/browse/TEIID-5908
> Project: Teiid
> Issue Type: Bug
> Reporter: Chandra Akkinepalli
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.x
>
>
> Our data source is redshift and we are using redshift translator in JDV.
> The source table has a couple of fields with data type "timestamp with timezone". This is field is mapped to Teiid source model with a data type timestamp. For some reason we are receiving following error when running a query on the table with this field in VDB.
> *"SQL Error [30504] [50000]: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 SRC_RS_HYDRA: 22003 Unexpected exception while translating results: [Amazon][JDBC](10140) Error converting value to Timestamp"*
> The fields which have source data type of "timestamp without timezone" mapped to teiid data type of timestamp work just fine.
> Please let me know if you have any questions.
> Thanks,
> Chandra
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (TEIID-5852) views are resolved twice in the metadata validator
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5852?focusedWorklogId=12450347&pag... ]
Steven Hawkins logged work on TEIID-5852:
-----------------------------------------
Author: Steven Hawkins
Created on: 28/Feb/20 1:13 PM
Start Date: 28/Feb/20 1:13 PM
Worklog Time Spent: 2 hours, 30 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 2 hours, 30 minutes (was: 5 hours)
Time Spent: 2 hours, 30 minutes
Worklog Id: (was: 12450347)
> views are resolved twice in the metadata validator
> --------------------------------------------------
>
> Key: TEIID-5852
> URL: https://issues.redhat.com/browse/TEIID-5852
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Original Estimate: 5 hours
> Time Spent: 2 hours, 30 minutes
> Remaining Estimate: 2 hours, 30 minutes
>
> There is an initial resolve to run the Validation visitor, then another resolve in resolveView. This should be combined as much as possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months