April 2009 - teiid-issues - Jboss List Archives

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

by Tim Walsh (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-100?page=com.atlassian.jira.plug... ] Tim Walsh resolved TEIID-100. ----------------------------- Resolution: Done /teiid/connectors/connector-salesforce/src/main/java/com/metamatrix/connector/salesforce/connection/impl/ConnectionImpl.java added exception case. > 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: Tim Walsh > 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, 2 months

1
0
0 / 0

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

by Tim Walsh (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-100?page=com.atlassian.jira.plug... ] Tim Walsh reassigned TEIID-100: ------------------------------- Assignee: Tim Walsh (was: John Doyle) > 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: Tim Walsh > 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, 2 months

1
0
0 / 0

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

by Tim Walsh (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-96?page=com.atlassian.jira.plugi... ] Tim Walsh reassigned TEIID-96: ------------------------------ Assignee: Tim Walsh (was: John Doyle) > 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: Tim Walsh > 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, 2 months

1
0
0 / 0

[JBoss JIRA] Assigned: (TEIID-55) Salesforce connector doesn't expose standard connection pooling or caching connector properties

by Tim Walsh (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-55?page=com.atlassian.jira.plugi... ] Tim Walsh reassigned TEIID-55: ------------------------------ Assignee: Tim Walsh (was: John Doyle) > Salesforce connector doesn't expose standard connection pooling or caching connector properties > ----------------------------------------------------------------------------------------------- > > Key: TEIID-55 > URL: https://jira.jboss.org/jira/browse/TEIID-55 > Project: Teiid > Issue Type: Bug > Components: Salesforce Connector > Affects Versions: 6.x > Environment: SFDC Connector 5.5 GA; MM Designer 5.5.2 0037 Linux > Reporter: Greg Haber > Assignee: Tim Walsh > Fix For: 6.x > > > The connector framework provides both caching and pooling support for connectors that implement the required interfaces. The SFDC connector code does indeed implement all of these interfaces. > In order to allow users to fine tune caching or pooling behavior for a connector binding, the connector type's CDK file must also list all of the standard connector framework caching and pooling properties. The SFDC connector does not currently expose these properties. > The SFDC connector's CDK file should be updated to include these properties. Unfortunately we don't document in the connector developer's guide what properties should be defined, but this info can be found in the definition of any of the standard JDBC connector types (Oracle ANSI, etc). These can be marked as "advanced" properties for SFDC as they are for the JDBC connector types. > The max pooled connections per user property is especially important for SFDC, because of the hard limit on 5 concurrent server side cursors per user in SFDC. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Work started: (TEIID-252) Add constant cohersion to rewriter for comparison criteria.

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-252?page=com.atlassian.jira.plug... ] Work on TEIID-252 started by Steven Hawkins. > Add constant cohersion to rewriter for comparison criteria. > ----------------------------------------------------------- > > Key: TEIID-252 > URL: https://jira.jboss.org/jira/browse/TEIID-252 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.1.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > From a recent discussion with Larry, it would be good for the rewriter to handle situations like: > "convert(col, type1) = constant of type2" => "col = constant of type1", where type1 is something other than string. > We already have resolver logic to do this and in many circumstance failing to apply the narroring conversion would indicate a failing comparison. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-512) Simplify evaluatablevisitor

by Steven Hawkins (JIRA)

Simplify evaluatablevisitor --------------------------- Key: TEIID-512 URL: https://jira.jboss.org/jira/browse/TEIID-512 Project: Teiid Issue Type: Task Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 6.1.0 The evaluatablevisitor is using 4 booleans to represent possible evaluation states. This is overly complex and redundant. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Resolved: (TEIID-81) Cached plans are too big - can cause out of memory errors

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-81?page=com.atlassian.jira.plugi... ] Steven Hawkins resolved TEIID-81. --------------------------------- Resolution: Done Plan size reduction, removal of language object cloning, and sharing of non-session specific plans have all been implemented. Any further gains are expected to come from TEIID-511. For now though we should remove our KI on this topic, or at least provide better guidance on a reasonable size setting. > Cached plans are too big - can cause out of memory errors > --------------------------------------------------------- > > Key: TEIID-81 > URL: https://jira.jboss.org/jira/browse/TEIID-81 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #12381: Running the coper load tests led to this conclusion: > Each cached plan takes on average 31 KB of memory. > At 140 unique queries / connection and 128 connection this requires over 550 MB of memory just for the plan cache. > Half of the memory was consumed by char[]. Over 10% of the memory was used by ElementSymbol objects. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-514) ORDER BY should have ability to include columns not specified in the SELECT clause

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-514?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-514: --------------------------------- Fix Version/s: 6.2.0 Affects Version/s: 6.0.0 Assignee: (was: Steven Hawkins) Priority: Minor (was: Major) I should have been specific in saying that it was a non sql-92 feature (we claim to implement "select" sql-99 and later features). But I'm fine with reopening and targeting to 6.2.0. It may also require an additional connector capability. Also, the create table syntax is documented in the teiid/5.5.x references. > ORDER BY should have ability to include columns not specified in the SELECT clause > ---------------------------------------------------------------------------------- > > Key: TEIID-514 > URL: https://jira.jboss.org/jira/browse/TEIID-514 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Marc Shirley > Priority: Minor > Fix For: 6.2.0 > > > Client request to allow an ORDER BY clause to include columns other than those specified in the SELECT clause, as in the following query: > SELECT col1, col2, col3 > FROM tableA > ORDER BY col4 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-514) ORDER BY should have ability to include columns not specified in the SELECT clause

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-514?page=com.atlassian.jira.plug... ] Steven Hawkins moved JBEDSP-71 to TEIID-514: -------------------------------------------- Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-514 (was: JBEDSP-71) Component/s: Query Engine (was: Server) > ORDER BY should have ability to include columns not specified in the SELECT clause > ---------------------------------------------------------------------------------- > > Key: TEIID-514 > URL: https://jira.jboss.org/jira/browse/TEIID-514 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Marc Shirley > Assignee: Steven Hawkins > > Client request to allow an ORDER BY clause to include columns other than those specified in the SELECT clause, as in the following query: > SELECT col1, col2, col3 > FROM tableA > ORDER BY col4 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-105) MySQL capabilities should be made specific to version 4/5

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-105?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-105: -------------------------------------- Yes it's still valid. We have already downgraded the translator to only support 4.x. If we can choose not to make any changes to the translator, we should be sure to call it a MySQL version 4 connector. The intent of the issue was to really clarify version support. It could be a separate issue to create the 5.x translator. > MySQL capabilities should be made specific to version 4/5 > --------------------------------------------------------- > > Key: TEIID-105 > URL: https://jira.jboss.org/jira/browse/TEIID-105 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 6.x > Reporter: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24746: The current mysql capabilities seem to have been written for version 5 (it initially included support for timestampdiff). The support for 4.x should be specifically refined or specifically removed from the docs. 4.x goes completely eol by the end of 2009, so it's unlikely many customers would care if this were done for 5.5.1. > see also http://www.mysql.com/company/legal/lifecycle/#calendar -- 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, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2009