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

Tue Oct 6 13:51:49 EDT 2009

    [ https://jira.jboss.org/jira/browse/TEIID-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12488663#action_12488663 ] 

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