October 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Resolved: (TEIID-222) Procedural relational execution should support disjunctive criteria

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-222?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-222. ---------------------------------- Resolution: Duplicate Issue Marking as a duplicate of TEIID-183 (which was deferred). It is the general case for query expansion with disjunctive criteria. > Procedural relational execution should support disjunctive criteria > ------------------------------------------------------------------- > > Key: TEIID-222 > URL: https://jira.jboss.org/jira/browse/TEIID-222 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.3 > > > Defect Tracker #24820: Disjunctive criteria should be supported for procedure execution, i.e. select * from proc where input1 = 1 or input2 = 2. Note that for this to work it will to know the possible values for missing parameters in each of the disjuncts, which is covered by defect 24821. Otherwise each disjunct must fully specify all parameters, i.e. (input1 = 1 and input2 = 2) or (input1 = 2 and input2 = 3) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-236) Procedural access pattern

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-236?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-236. ---------------------------------- Resolution: Deferred I'm inclined to not add the procedural access pattern as a separate concern. Teiid already appropriately checks for valid subset of procedural criteria in RulePlanProcedures. Also from a designer perspective determining when an access pattern is a procedural access pattern would simply involve checking the covered group to see if it resolves to a procedure. There is a case to be made that our normal concept of an access pattern should be the same thing as a "procedural" access pattern. That would predictably restrict the rows returned, work with procedural relational logic, and be valid for use with source indexes. However that would be a breaking change and has not yet been a requested feature. > Procedural access pattern > ------------------------- > > Key: TEIID-236 > URL: https://jira.jboss.org/jira/browse/TEIID-236 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 6.3 > > > Defect Tracker #24374: It would be good to introduce a concept of a procedural access pattern (with designer support) that would capture the more restrictive semantics of procedure input criteria (=, in, and is null). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-93) when a fairly complex query is pushed down to the XML-HTTP Connector, it fails

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-93?page=com.atlassian.jira.plugi... ] Steven Hawkins commented on TEIID-93: ------------------------------------- This type of issue will be fixed in general when we migrate the xml relational logic into the engine and model document retrieval as a procedure. The procedural relational logic would already correctly handle this situation. > when a fairly complex query is pushed down to the XML-HTTP Connector, it fails > ------------------------------------------------------------------------------ > > Key: TEIID-93 > URL: https://jira.jboss.org/jira/browse/TEIID-93 > Project: Teiid > Issue Type: Bug > Components: XML Connector > Affects Versions: 7.x > Reporter: Steven Hawkins > Fix For: 6.3 > > > Defect Tracker #25059: when a fairly complex query is pushed down to the XML-HTTP > Connector, it fails > Need a lot more information. > OK, here's how to reproduce this issue (which we hit at Citi). Use the attached model project set in 5.5.1RC2 Designer, and use the response.xml attached with your standard xmltool.war tester. Then issue the following query from Designer: > >> > >> select H_RelationshipID, H_RelationshipName, H_HHID, H_TeamLeadName, H_TeamLeadID, H_MemberFirstName, H_MemberLastName, H_MemberAcctID, H_MemberFCName, H_MemberFCNum, H_HHLeadInd, H_MemberType, H_MemberRole, H_clientId, A_ADDR_TYPE, A_ADDR_SUB_TYPE, A_ADDR_SUB_NAME, A_ADDR_LINE1, A_ADDR_LINE2, A_ADDR_LINE3, A_ADDR_LINE4, A_ADDR_LINE5, A_ADDR_LINE6, A_ADDR_FLAG1, A_ADDR_FLAG2, A_ADDR_FLAG3, A_ADDR_FLAG4, A_ADDR_FLAG5, A_ADDR_FLAG6, A_CITY, A_ZIP, A_STATE_CODE, A_POSTAL_CODE, A_COUNTRY, A_ALTA_TYPE, A_EFF_DATE, A_EXP_DATE from "RPXMLTest"."CustRelnDataWS.WS.RetrieveCustRelnData.relnDataSingleTable" where A_ADDR_TYPE IN ('BA','AA') AND ((A_ADDR_TYPE IN('AA')) AND(NVL(A_ALTA_TYPE,'') = '')) > >> > >> This plans to the following source query being pushed to the connector: > >> > >> SELECT A_ALTA_TYPE, H_RelationshipID, H_RelationshipName, H_HHID, H_TeamLeadName, H_TeamLeadID, H_MemberFirstName, H_MemberLastName, H_MemberAcctID, H_MemberFCName, H_MemberFCNum, H_HHLeadInd, H_MemberType, H_MemberRole, H_clientId, A_ADDR_TYPE, A_ADDR_SUB_TYPE, A_ADDR_SUB_NAME, A_ADDR_LINE1, A_ADDR_LINE2, A_ADDR_LINE3, A_ADDR_LINE4, A_ADDR_LINE5, A_ADDR_LINE6, A_ADDR_FLAG1, A_ADDR_FLAG2, A_ADDR_FLAG3, A_ADDR_FLAG4, A_ADDR_FLAG5, A_ADDR_FLAG6, A_CITY, A_ZIP, A_STATE_CODE, A_POSTAL_CODE, A_COUNTRY, A_EFF_DATE, A_EXP_DATE FROM RPXMLTest.CustRelnDataWS.WS.RetrieveCustRelnData.relnDataSingleTable WHERE (A_ADDR_TYPE IN ('BA', 'AA')) AND (A_ADDR_TYPE = 'AA') > >> > >> Now, the criteria here says that A_ADDR_TYPE needs to be in the set of 'AA', 'BA', AND needs to be equal to 'AA'. So really only those "rows" where A_ADDR_TYPE='AA' should be returned. But instead the connector returns all rows where A_ADDR_TYPE is 'AA' or 'BA'. > >> > > > > This seems like it could be a defect in the way we hande IN criteria. Was there ever a case or defect on this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-150) Improve nested loop (in merge join) matching

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-150?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-150. ---------------------------------- Resolution: Won't Fix This is probably not worth the effort, since the match loop was not written for batch handling. This would only be an issue for large nested loop joins (or match regions with lots of duplicates), which will already have poor performance. > Improve nested loop (in merge join) matching > --------------------------------------------- > > Key: TEIID-150 > URL: https://jira.jboss.org/jira/browse/TEIID-150 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.3 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Nested loop evaluation should be based upon available blocks rather than fully iterating the inner side. The simplest approach is to just match a single block from the left and right at a time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-404) 1-way and 2-way SSL to MMx must support different keystore file names within a cluster

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-404?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-404. ---------------------------------- Resolution: Out of Date SSL configuration is now in the deploy.properties, which would be configured for each cluster member. > 1-way and 2-way SSL to MMx must support different keystore file names within a cluster > -------------------------------------------------------------------------------------- > > Key: TEIID-404 > URL: https://jira.jboss.org/jira/browse/TEIID-404 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 6.1.0 > Reporter: Larry O'Leary > Fix For: 6.3 > > > Defect Tracker #24283: File naming conventions require a keystore file to be prefixed with the machine's host name. This creates a problem when deploying certificates for use with SSL to a MetaMatrix System as the keystore on each MetaMatrix Server has a different name. Currently, the MMConsole only allows you to set a key store file name that will be used system wide. > We will need the ability to define a key store file name on a per host and possibly a per VM basis. This could be accomplished in many different manners. > The recommended implementation would be to simply move the SSL Resource configuration to the process and host level. This would allow an administrator to continue to use the Console to configure SSL. > At the host level, the administrator could set the default key store file name to be used for all VM(s) deployed to that host. At the VM level, the administrator could set a key store file name value that will override the default host level key store file name property. > This should also be done for the client trust store property to support 2-way SSL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-183) user "or" and "in" criteria should generate multiple queries in some situations

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-183?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-183. ---------------------------------- Resolution: Deferred both the xml connector and proc relational now support in. The only scenario that is not covered is the use of or - which for multiple parameter values should just be written as an in. In general there's a case to be made to support a or b as a and not(b) union all b and not(a) union all a and b OR for distinct results as a union b. This query expansion should only be done when both a and b are both separately supported for pushdown and result in significantly less rows being returned than the query without criteria. Marking as deferred until a compelling use case comes up for this scenario. > user "or" and "in" criteria should generate multiple queries in some situations > ------------------------------------------------------------------------------- > > Key: TEIID-183 > URL: https://jira.jboss.org/jira/browse/TEIID-183 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.x > Reporter: Steven Hawkins > Fix For: 6.3 > > > Defect Tracker #23857: Since web services and relational wrappers around procedures do not support "in" or "or" criteria, an enhancement would be union the results of multipe queries rather than not pushing down the criteria or not validating the query entirely. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-41) Non selectable columns should be omitted from metadata

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-41?page=com.atlassian.jira.plugi... ] Steven Hawkins resolved TEIID-41. --------------------------------- Resolution: Out of Date Non-selectable columns were only introduced to represent procedure input columns, since procedural relational logic no supports projection of inputs there isn't really a need to continue with the concept of non-selectable columns. They may be in use on xml relational input tables, but if those are changed to also be procedures, then there's no issue there either. > Non selectable columns should be omitted from metadata > ------------------------------------------------------ > > Key: TEIID-41 > URL: https://jira.jboss.org/jira/browse/TEIID-41 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.x > Reporter: Steven Hawkins > Fix For: 6.3 > > > Defect Tracker #24612: Non-selectable columns should not be visible in metadata. When visible they will lead to invalid sql getting generated (there was a SQL Explorer defect to that effect, but I can't find it at this time). This is not a regression in 5.5 in 5.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-186) Expose catalog information and props in Connector API metadata [PEC]

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-186?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-186: --------------------------------- Fix Version/s: 7.0 (was: 6.3) Affects Version/s: 6.0.0 (was: 7.x) Complexity: Medium Moving to 7.0 > Expose catalog information and props in Connector API metadata [PEC] > -------------------------------------------------------------------- > > Key: TEIID-186 > URL: https://jira.jboss.org/jira/browse/TEIID-186 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 7.0 > > > Defect Tracker #20304: This request is to expose information on catalogs and schemas in relational models as separate entities and also to expose extension properties on those entities. Currently, only models and groups exist in runtime indexes and Connector API metadata and catalogs and schemas are just treated as namespace elements for groups. The XML Connector uses those catalogs and would like to store extension properties on them and retrieve those in the connector. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-26) Need to add logic to determine if a command is deterministic

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-26?page=com.atlassian.jira.plugi... ] Steven Hawkins resolved TEIID-26. --------------------------------- Resolution: Done The evaluatorvisitor can be used statically and the commandcontext sessionFunctionEvaluated flag can be used after planning/processing to verify the level of determinism. > Need to add logic to determine if a command is deterministic > ------------------------------------------------------------ > > Key: TEIID-26 > URL: https://jira.jboss.org/jira/browse/TEIID-26 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.x > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.3 > > > Defect Tracker #24669: A recent case removed the logic in dependentselectnode that did not reexecute a subquery if it did not have correlated references. This logic can be added back if we can check if the command is deterministic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-216) Query timeout should be enforced by the server

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-216?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-216. ---------------------------------- Resolution: Deferred Marking as deferred. Zero sized batch processing is a very minor issue, once a timeout or cancel has been issued the current plan will typically fail-fast. Also we will now get immediate notification of a failing client connection, or at the very least a ping timeout that will cause a cancel. Until we clients accessing through a non-Java interface it's not imperative to move/duplicate the timeout handling on the server. > Query timeout should be enforced by the server > ---------------------------------------------- > > Key: TEIID-216 > URL: https://jira.jboss.org/jira/browse/TEIID-216 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 6.3 > > > Defect Tracker #4990 : Query timeouts should be enforced by the server and client. > Also the RelationalNode nextbatch method will need to be made aware of the timeslice/timeout when handling 0 length batches. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues October 2009