December 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Work started: (TEIID-855) CTC is producting unexpected results due to case sensitive issues between different sources

by Van Halbert (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-855?page=com.atlassian.jira.plug... ] Work on TEIID-855 started by Van Halbert. > CTC is producting unexpected results due to case sensitive issues between different sources > ------------------------------------------------------------------------------------------- > > Key: TEIID-855 > URL: https://jira.jboss.org/jira/browse/TEIID-855 > Project: Teiid > Issue Type: Bug > Components: Integration Tests > Affects Versions: 7.0 > Reporter: Warren Gibson > Assignee: Van Halbert > > We found it necessary to do fresh imports from all the query sources. In doing so we found that some of the sources contain table and column names in all caps. This is causing non compare results when exceptions are thrown and the exception error messages are compared. Upper and Lower case should not create a non compare. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Closed: (TEIID-855) CTC is producting unexpected results due to case sensitive issues between different sources

by Van Halbert (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-855?page=com.atlassian.jira.plug... ] Van Halbert closed TEIID-855. ----------------------------- > CTC is producting unexpected results due to case sensitive issues between different sources > ------------------------------------------------------------------------------------------- > > Key: TEIID-855 > URL: https://jira.jboss.org/jira/browse/TEIID-855 > Project: Teiid > Issue Type: Bug > Components: Integration Tests > Affects Versions: 7.0 > Reporter: Warren Gibson > Assignee: Van Halbert > > We found it necessary to do fresh imports from all the query sources. In doing so we found that some of the sources contain table and column names in all caps. This is causing non compare results when exceptions are thrown and the exception error messages are compared. Upper and Lower case should not create a non compare. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-207) Forward and Backward Compatibility of MetaMatrix JDBC Driver

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-207?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-207: --------------------------------- Fix Version/s: 7.1 (was: 7.0) Moving to 7.1. The 7.0 driver will not be backwards compatible. There's been too many changes related to parameters and jdbcdatabasemetadata. Moving to 7.1 to ensure compatibility with 7.0. More than likely a switch to a stable binary protocol will wait until 8 > Forward and Backward Compatibility of MetaMatrix JDBC Driver > ------------------------------------------------------------ > > Key: TEIID-207 > URL: https://jira.jboss.org/jira/browse/TEIID-207 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Driver > Affects Versions: 6.0.0 > Reporter: Marc Shirley > Fix For: 7.1 > > > The MetaMatrix JDBC driver should be forward and backward compatible with newer/older versions of Enterprise Server. It is understood that certain protocol changes may break the compatibility but this should only happen in major releases and not affect Service Packs and maintenance releases. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-143) Query should 'find' connector types and jars rather than have them predefined in the config.

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-143?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-143: ------------------------------------ Connector will be a JCA component and will use RAR package format and deployed as such into a container. This satisfies most of the requirements. > Query should 'find' connector types and jars rather than have them predefined in the config. > -------------------------------------------------------------------------------------------- > > Key: TEIID-143 > URL: https://jira.jboss.org/jira/browse/TEIID-143 > Project: Teiid > Issue Type: Sub-task > Components: Misc. Connectors > Affects Versions: 6.0.0 > Reporter: John Doyle > Fix For: 7.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently, dqp as delived with Designer is preconfigured with connector types. I think it should discover the connectors that are available upon startup. This would make it easier to add connectors to a kit. The current process for adding a connector to a kit is manual and error prone. We have problems with it on nearly every release. > This is also an attractive feature for embedding query in other environments. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-143) Query should 'find' connector types and jars rather than have them predefined in the config.

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-143?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIID-143: ------------------------------- Parent: TEIID-833 Issue Type: Sub-task (was: Feature Request) > Query should 'find' connector types and jars rather than have them predefined in the config. > -------------------------------------------------------------------------------------------- > > Key: TEIID-143 > URL: https://jira.jboss.org/jira/browse/TEIID-143 > Project: Teiid > Issue Type: Sub-task > Components: Misc. Connectors > Affects Versions: 6.0.0 > Reporter: John Doyle > Fix For: 7.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently, dqp as delived with Designer is preconfigured with connector types. I think it should discover the connectors that are available upon startup. This would make it easier to add connectors to a kit. The current process for adding a connector to a kit is manual and error prone. We have problems with it on nearly every release. > This is also an attractive feature for embedding query in other environments. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-180) Consider using Salesforce retrieve() rather than generic query() call for queries with IN criteria

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-180?page=com.atlassian.jira.plug... ] John Doyle resolved TEIID-180. ------------------------------ Resolution: Done Retrieve will now be used if the object supports the call (not all do) and if it's only id paramters in the IN. > Consider using Salesforce retrieve() rather than generic query() call for queries with IN criteria > -------------------------------------------------------------------------------------------------- > > Key: TEIID-180 > URL: https://jira.jboss.org/jira/browse/TEIID-180 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0, 6.1.0, 6.2.0 > Environment: MM 5.5.2 patch 0037/SFDC GA connector > Reporter: Greg Haber > Assignee: John Doyle > Fix For: 7.0 > > > One of the usage guidelines for the SFDC WS API (http://blog.sforce.com/sforce/2005/04/performance_tip.html) says > Get familiar with the retrieve call. If you are pulling data from related tables, the retrieve call is a high performance call that you should be using > So I looked up retrieve() in the API doc (http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_calls_...) > It looks like retrieve() is a special purpose call that gives high performance when you want to retrieve a list of records from an object by object Id. It lets you select which fields you want returned (and I believe their order), but does not allow any functions on those fields, or any additional criteria beyond this object list. > At first, this sounds like a very limited case, but in fact this is essentially the case we have in the SFDC connector when MM plans out a query as a dep join, with an SFDC table as the dependent source. In fact the API doc specifically recommends retrieve() for this case: > Client applications can use retrieve() to perform a client-side join. For example, a client application can run a query() to obtain a set of Opportunity records, iterate through the returned opportunity records, obtain the accountId for each opportunity, and then call retrieve() to obtain Account information for those accountIds. > We may want to implement this special case in the SFDC connector - if a query has as criteria only a single IN clause, and that IN clause is on the Id column, then use retrieve rather than query. > If we implement relationship joins in the SFDC connector, then this optimization is largely irrelevant - so this is a potential fallback or stopgap if we don't want to tackle relationship joins just yet. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-218) Security URL properties handling

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-218?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-218: --------------------------------- Parent: TEIID-833 Issue Type: Sub-task (was: Feature Request) > Security URL properties handling > -------------------------------- > > Key: TEIID-218 > URL: https://jira.jboss.org/jira/browse/TEIID-218 > Project: Teiid > Issue Type: Sub-task > Components: JDBC Driver, Server > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 7.0 > > > Defect Tracker #24196: Security URL properties are currently a mess in that there are three properties, clientToken, credentials, and trustedPayload that are all eventually treated at the trustedPayload. This is not desirable. Instead we should pass all of the connection properties to the membership service (as a map) for access by membership domains. This would remove the need to specifically pass the trustedPayload and application name as parameters. This could also be done for connectors provided that the message or the transport containing the connection properties is encrypted. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-180) Consider using Salesforce retrieve() rather than generic query() call for queries with IN criteria

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-180?page=com.atlassian.jira.plug... ] John Doyle updated TEIID-180: ----------------------------- Fix Version/s: 7.0 (was: 8.x) Affects Version/s: 6.2.0 6.1.0 6.0.0 (was: 8.x) > Consider using Salesforce retrieve() rather than generic query() call for queries with IN criteria > -------------------------------------------------------------------------------------------------- > > Key: TEIID-180 > URL: https://jira.jboss.org/jira/browse/TEIID-180 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0, 6.1.0, 6.2.0 > Environment: MM 5.5.2 patch 0037/SFDC GA connector > Reporter: Greg Haber > Assignee: John Doyle > Fix For: 7.0 > > > One of the usage guidelines for the SFDC WS API (http://blog.sforce.com/sforce/2005/04/performance_tip.html) says > Get familiar with the retrieve call. If you are pulling data from related tables, the retrieve call is a high performance call that you should be using > So I looked up retrieve() in the API doc (http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_calls_...) > It looks like retrieve() is a special purpose call that gives high performance when you want to retrieve a list of records from an object by object Id. It lets you select which fields you want returned (and I believe their order), but does not allow any functions on those fields, or any additional criteria beyond this object list. > At first, this sounds like a very limited case, but in fact this is essentially the case we have in the SFDC connector when MM plans out a query as a dep join, with an SFDC table as the dependent source. In fact the API doc specifically recommends retrieve() for this case: > Client applications can use retrieve() to perform a client-side join. For example, a client application can run a query() to obtain a set of Opportunity records, iterate through the returned opportunity records, obtain the accountId for each opportunity, and then call retrieve() to obtain Account information for those accountIds. > We may want to implement this special case in the SFDC connector - if a query has as criteria only a single IN clause, and that IN clause is on the Id column, then use retrieve rather than query. > If we implement relationship joins in the SFDC connector, then this optimization is largely irrelevant - so this is a potential fallback or stopgap if we don't want to tackle relationship joins just yet. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-250) Enable Axis data compression in SFDC Connector, per SFDC API guidelines

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-250?page=com.atlassian.jira.plug... ] John Doyle updated TEIID-250: ----------------------------- Fix Version/s: 7.1 (was: 7.0) > Enable Axis data compression in SFDC Connector, per SFDC API guidelines > ----------------------------------------------------------------------- > > Key: TEIID-250 > URL: https://jira.jboss.org/jira/browse/TEIID-250 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0 > Environment: MetaMatrix 5.5.2 with patch 0037/SFDC GA connector > Reporter: Greg Haber > Assignee: John Doyle > Fix For: 7.1 > > > The SFDC doc includes a set of performance guidelines for using their API (http://blog.sforce.com/sforce/2005/04/performance_tip.html). One of the guidelines: > Use compression, unless you have an OC45 connection into the back of your machine, compression will help reduce transmission times, the Sforce API supports gzip and deflate compression for both request and response. > does not look like it has been implemented in our connector. In theory, this will be a big optimization when returning large data sets, as is the case at Genentech. This is also a trivial optimization to implement, so we should at least try this out and see what the impact is. > The process for enabling this is described on http://wiki.apexdevnet.com/index.php/Compression_with_Axis_1.3 - essentially, you subclass the SforceServiceLocator class in the salesforce.jar to set a few Axis-specific properties (complete code for subclass is at the link), and then in our connector (in ConnectionImpl) we call this subclass instead of calling the SforceServiceLocator directly, as we are doing today. > This is a very low hanging fruit with a big upside - please implement soon. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-211) subquery optimization

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-211?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-211: --------------------------------- Fix Version/s: 7.1 (was: 7.0) > subquery optimization > --------------------- > > Key: TEIID-211 > URL: https://jira.jboss.org/jira/browse/TEIID-211 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 7.1 > > > Implement rewriter (and planner) optimizations for subqueries based upon semi and anti semi join capabilities. -- 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, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues December 2009