February 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Updated: (TEIID-100) Salesforce connector should explicitly handle InvalidQueryLocatorFault

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-100?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIID-100: ------------------------------- Component/s: Salesforce Connector Fix Version/s: 6.x Affects Version/s: 6.x > Salesforce connector should explicitly handle InvalidQueryLocatorFault > ---------------------------------------------------------------------- > > Key: TEIID-100 > URL: https://jira.jboss.org/jira/browse/TEIID-100 > Project: Teiid > Issue Type: Bug > Components: Salesforce Connector > Affects Versions: 6.x > Environment: SFDC 5.5GA Connector; MM Designer 5.5.2 0037 Linux > Reporter: Greg Haber > Assignee: John Doyle > Fix For: 6.x > > > There is a hard limit of 5 on the number of handles a single Salesforce user can have to server side result sets - see http://www.salesforce.com/us/developer/docs/api100/Content/sforce_api_cal... > This means, that in cases where a customer is doing a lot of queries that return large result sets (larger than SF will return in a single SOAP response), it is very possible that they will run into this limit. This limit should manifest itself as an InvalidQueryLocatorFault thrown when the Salesforce queryMore() operation is called. > I see in the current code (queryMore method of com.metamatrix.connector.salesforce.connection.impl.ConnectionImpl) that we don't explicitly catch this fault. We should catch this fault and throw a ConnectorException that clearly explains what is happening (if the message SFDC returns here isn't clear enough). -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-99) Stored procedures should work in multisource connector binding scenarios

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-99?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-99: ------------------------------ Component/s: Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.x > Stored procedures should work in multisource connector binding scenarios > ------------------------------------------------------------------------ > > Key: TEIID-99 > URL: https://jira.jboss.org/jira/browse/TEIID-99 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24614: Stored procedures should work in multisource connector binding scenarios by adding another input parameter named SOURCE_NAME -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-97) add proper SQLState for timeout/cancel

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-97?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-97: ------------------------------ Component/s: JDBC Driver Fix Version/s: 6.x Affects Version/s: 6.x > add proper SQLState for timeout/cancel > -------------------------------------- > > Key: TEIID-97 > URL: https://jira.jboss.org/jira/browse/TEIID-97 > Project: Teiid > Issue Type: Bug > Components: JDBC Driver > Affects Versions: 6.x > Reporter: Steven Hawkins > Priority: Trivial > Fix For: 6.x > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Query timeouts/cancel should set the SQLState to 57014 -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-96) Salesforce connector isn't consistently protecting against null values in binding parameters

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-96?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-96: ------------------------------ Component/s: Salesforce Connector Fix Version/s: 6.x Affects Version/s: 6.x > Salesforce connector isn't consistently protecting against null values in binding parameters > -------------------------------------------------------------------------------------------- > > Key: TEIID-96 > URL: https://jira.jboss.org/jira/browse/TEIID-96 > Project: Teiid > Issue Type: Bug > Components: Salesforce Connector > Affects Versions: 6.x > Environment: 5.5.2 with patch 0050; Salesforce connector with patch p552_080717_0001 > Reporter: Greg Haber > Assignee: John Doyle > Priority: Minor > Fix For: 6.x > > > The GA release of the SFDC connector had one binding parameter that should have a number value - InLimit. The p552_080717_0001 patch adds a second - PingInterval. > When these parameters are actually read by the connector in com.metamatrix.connector.salesforce.connection.SalesforceConnection, the connector tries to use Integer.decode or Long.decode to convert these values to the correct numeric type from the String that is returned by the Properties object. There is no checking to see if the values here are null before calling the decode method, so the connector bombs out with an NPE if either value is null. > We should either silently fall back on a default value or throw an appropriate ConnectorException if these values are null, but we shouldn't be throwing an NPE. > I looked through the code and it looks like we are careful with checking for nulls for the other SFDC connector binding parameters. > Also, I noticed that both of these parameters are defined in the connector binding type's CDK file as type String, instead of the correct numeric type. I don't know if setting the type correctly in the CDK file would actually add some extra validation in this case, but we should set the types correctly here in case we do (or if we don't, to take advantage of such validation if we add it in a later release). Using correct numeric types would also make this connector type definition consistent with the other standard MMx connectors, where these types are widely used. -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-98) Prepared/CallableStatement parameter indexes are not correct.

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-98?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-98: ------------------------------ Component/s: Query Engine Fix Version/s: 6.x Affects Version/s: 6.x > Prepared/CallableStatement parameter indexes are not correct. > ------------------------------------------------------------- > > Key: TEIID-98 > URL: https://jira.jboss.org/jira/browse/TEIID-98 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Priority: Minor > Fix For: 6.x > > Original Estimate: 2 days > Remaining Estimate: 2 days > > All parameter indexes are treated as relative rather than absolute. We should not accept values less than 1 and should ensure that the values specified are continuous. > Also, return parameters should be considered index 1 regardless of where they are in the procedure metadata. For example in defer_testDefect24952 in TestMMStoredProcedure ?=call sp.sp_count_rows_between(?, ?) should have a return value at index 1 from the driver perspective, but instead it has index 3. > see also defect 24952 -- 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

15 years, 10 months

1
0
0 / 0

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

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-93?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-93: ------------------------------ Component/s: XML Connector Fix Version/s: 6.x Affects Version/s: 6.x > 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: 6.x > Reporter: Steven Hawkins > Fix For: 6.x > > > 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-89) Data roles should account for the ability to create temp tables

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-89?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-89: ------------------------------ Component/s: Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.x > Data roles should account for the ability to create temp tables > --------------------------------------------------------------- > > Key: TEIID-89 > URL: https://jira.jboss.org/jira/browse/TEIID-89 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.1.0 > > > Defect Tracker #24698: Data roles should account for creating temp tables. Right now all temp table creation is allowed. -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-88) Add WS-Security Support with Sandesha2

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-88?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-88: ------------------------------ Component/s: SOAP Services Fix Version/s: 6.x Affects Version/s: 6.x > Add WS-Security Support with Sandesha2 > -------------------------------------- > > Key: TEIID-88 > URL: https://jira.jboss.org/jira/browse/TEIID-88 > Project: Teiid > Issue Type: Bug > Components: SOAP Services > Affects Versions: 6.x > Reporter: Steven Hawkins > Assignee: Ted Jones > Priority: Minor > Fix For: 6.x > > > Defect Tracker #24315: WS-Security (Rampart 1.2) engaged with WS-RM (Sandesha2 1.2) is not working in Axis2 1.2. Need to stay on top of this and implement/test with next Axis2 release. Users will need to use HTTP Basic Authentication when WS-RM is required until the issue is resolved. -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-84) "Expression's Type was null" Error Executing Query against XML Document

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-84?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-84: ------------------------------ Component/s: Query Engine Fix Version/s: 6.x Affects Version/s: 6.x > "Expression's Type was null" Error Executing Query against XML Document > ----------------------------------------------------------------------- > > Key: TEIID-84 > URL: https://jira.jboss.org/jira/browse/TEIID-84 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Ted Jones > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.x > > Attachments: catalog_MPS.zip, StackTrace.txt > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Received an error, "Expression's Type was null", executing a query against the XML Document created in the E2E Books Catalog test script. MPS and stack trace attached. -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-86) registering of CallableStatement out parameters should be used

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-86?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-86: ------------------------------ Component/s: Query Engine Fix Version/s: 6.x Affects Version/s: 6.x > registering of CallableStatement out parameters should be used > -------------------------------------------------------------- > > Key: TEIID-86 > URL: https://jira.jboss.org/jira/browse/TEIID-86 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Priority: Minor > Fix For: 6.x > > Original Estimate: 3 days > Remaining Estimate: 3 days > > The registering of CallableStatement out (out, inout, return) parameters should be used to > 1. help resolve the procedure - if there is a type mismatch or a parameter requested that doesn't exist an exception should be thrown. > 2. determine what out parameters the driver should know about. currently the driver is supplied with all out values regardless of how many are registered. this means that the user may not get the right value if the statement does not fully specifier all out parameters. -- 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

15 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2009