[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 hour, 37 minutes
[JBoss JIRA] (TEIIDSB-100) move static handling to the root context
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-100?page=com.atlassian.jira.plugi... ]
Steven Hawkins resolved TEIIDSB-100.
------------------------------------
Resolution: Done
Moved static handling to the root and simplified the logic dealing with the baseurl. Also removed the authenticationinterceptor and the alt paths logic as they are no longer needed.
> move static handling to the root context
> ----------------------------------------
>
> Key: TEIIDSB-100
> URL: https://issues.jboss.org/browse/TEIIDSB-100
> Project: Teiid Spring Boot
> Issue Type: Quality Risk
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 1.2.0
>
>
> To prevent conflicts with entity and schema names, static handling should be moved to the root level:
> /odata/...
> /static/...
> rather than
> /odata/static
> It's also a good idea to fully restrict the resources that can be read as all xml files in the unified classpath are currently accessible.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (TEIID-5741) Upgrade to Thorntail 2.4
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5741?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5741:
---------------------------------------
Switched to Teiid 12.2 with thorntail 2.4 on my shawkins/teiid-thorntail with no problems. Tested starting with Java 11, and that worked just fine. Will hold off for Teiid 12.2.1 and then cut this release.
> Upgrade to Thorntail 2.4
> ------------------------
>
> Key: TEIID-5741
> URL: https://issues.jboss.org/browse/TEIID-5741
> Project: Teiid
> Issue Type: Feature Request
> Components: thorntail
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: tt-2.1.0
>
>
> As a likely terminal release, we should provide Java 11 support via Thorntail 2.4.
> Since 2.4 is based upon WildFly 15.0.1, this will likely be off of 12.2.x, rather than 12.3.x.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-101) OData issues with multiple visible schema
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-101?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIIDSB-101:
----------------------------------------
Yes, I know that syndesis won't use it. But we've left it as a grey are for just engine usage. Assumptions around what constitutes a default model also seem problematic.
> OData issues with multiple visible schema
> -----------------------------------------
>
> Key: TEIIDSB-101
> URL: https://issues.jboss.org/browse/TEIIDSB-101
> Project: Teiid Spring Boot
> Issue Type: Quality Risk
> Components: OData
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.2.0
>
>
> The odata logic accommodates a subcontext specifying the schema to access. Other logic however doesn't allow for this:
> * if multiple visible schema are exposed and have a cross reference, then the metadata links will be invalid as they are created based upon the Teiid Wildfly conventions.
> * The keycloak logic exposes /$metadata as unsecured, but any of the schema/$metadata links would require authentication.
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-101) OData issues with multiple visible schema
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-101?page=com.atlassian.jira.plugi... ]
Ramesh Reddy commented on TEIIDSB-101:
--------------------------------------
schema/$metadata model will not be used syndesis. But is there way pattern match to $metadata as endpoint would be good.
> OData issues with multiple visible schema
> -----------------------------------------
>
> Key: TEIIDSB-101
> URL: https://issues.jboss.org/browse/TEIIDSB-101
> Project: Teiid Spring Boot
> Issue Type: Quality Risk
> Components: OData
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.2.0
>
>
> The odata logic accommodates a subcontext specifying the schema to access. Other logic however doesn't allow for this:
> * if multiple visible schema are exposed and have a cross reference, then the metadata links will be invalid as they are created based upon the Teiid Wildfly conventions.
> * The keycloak logic exposes /$metadata as unsecured, but any of the schema/$metadata links would require authentication.
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (TEIID-5710) Create remaining spring docs
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5710?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5710.
-----------------------------------
Resolution: Done
Marking the initial effort as resolved. The security guide is the only doc that has nothing of value to add to teiid-spring-boot as all configuration options and functionality has changed.
> Create remaining spring docs
> ----------------------------
>
> Key: TEIID-5710
> URL: https://issues.jboss.org/browse/TEIID-5710
> Project: Teiid
> Issue Type: Sub-task
> Components: Documentation
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.3
>
>
> Presuming that the embedded, dev, and security docs will all be available as part of their respective code (javadocs and examples), that leaves admin, caching, and client-dev as the remaining books that need a spring specific spin.
> Most of the admin guide is not applicable - but we do need to capture somewhere all of the information related to system/env properties
> Most of the caching guide is TBD - but the sections on result set and other caching are still applicable.
> Most of the client guide is applicable to spring.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (TEIIDSB-101) OData issues with multiple visible schema
by Steven Hawkins (Jira)
Steven Hawkins created TEIIDSB-101:
--------------------------------------
Summary: OData issues with multiple visible schema
Key: TEIIDSB-101
URL: https://issues.jboss.org/browse/TEIIDSB-101
Project: Teiid Spring Boot
Issue Type: Quality Risk
Components: OData
Reporter: Steven Hawkins
Fix For: 1.2.0
The odata logic accommodates a subcontext specifying the schema to access. Other logic however doesn't allow for this:
* if multiple visible schema are exposed and have a cross reference, then the metadata links will be invalid as they are created based upon the Teiid Wildfly conventions.
* The keycloak logic exposes /$metadata as unsecured, but any of the schema/$metadata links would require authentication.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (TEIID-5757) Remove the need for the odata role
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5757:
-------------------------------------
Summary: Remove the need for the odata role
Key: TEIID-5757
URL: https://issues.jboss.org/browse/TEIID-5757
Project: Teiid
Issue Type: Quality Risk
Components: OData
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.3
Similar to TEIIDSB-85 the rationale for having an odata role no longer seems valid. It will simplify usage if that is no longer required.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (TEIID-5756) null session query output from PDI
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5756?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5756.
-----------------------------------
Resolution: Out of Date
Advised about disabling the server ping check.
> null session query output from PDI
> ----------------------------------
>
> Key: TEIID-5756
> URL: https://issues.jboss.org/browse/TEIID-5756
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Environment: Prod
> Reporter: CHANDAN BISHT
> Priority: Major
> Attachments: jdvapp1.tar.gz, jdvapp3.tar.gz, server.log.1
>
>
> User getting null session query executed from PDI tool.
> the session id tvgWrPf4oPvD
> 2019-02-04 09:21:42,987 [New I/O worker #39] WARN [org.teiid.PROCESSOR] TEIID40011 Processing exception 'TEIID40042 Invalid Session tvgWrPf4oPvD. Session may have already been terminated.' for session null. Exception type org.teiid.client.security.InvalidSessionException thrown from org.teiid.jboss.TransportService$2.invoke(TransportService.java:239).: org.teiid.client.security.InvalidSessionException: TEIID40042 Invalid Session tvgWrPf4oPvD. Session may have already been terminated.
> at org.teiid.jboss.TransportService$2.invoke(TransportService.java:239)
> at com.sun.proxy.$Proxy20.processCursorRequest(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.teiid.transport.ServerWorkItem.run(ServerWorkItem.java:87)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
> at org.teiid.transport.SocketClientInstance.processMessagePacket(SocketClientInstance.java:231)
> at org.teiid.transport.SocketClientInstance.receivedMessage(SocketClientInstance.java:217)
> at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:216)
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleUpstream(ChunkedWriteHandler.java:142)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months