April 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Closed: (TEIID-127) Create a logging context specific to processing

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-127?page=com.atlassian.jira.plug... ] Steven Hawkins closed TEIID-127. -------------------------------- Resolution: Done Assignee: (was: Steven Hawkins) No new context was needed. changed to dqp context for processing logs. > Create a logging context specific to processing > ----------------------------------------------- > > Key: TEIID-127 > URL: https://jira.jboss.org/jira/browse/TEIID-127 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Minor > Fix For: 6.1.0 > > > Currently processing (com.metamatrix.query.processor) exceptions are mapped to the planner context. Either everything needs to be DQP or a specific context is needed. -- 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] Closed: (TEIID-19) Multiple subquery pushdown

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-19?page=com.atlassian.jira.plugi... ] Steven Hawkins closed TEIID-19. ------------------------------- Resolution: Done Assignee: (was: Steven Hawkins) Fixed as part of the reference handling change. See TestSubqueryPushdown. > Multiple subquery pushdown > -------------------------- > > Key: TEIID-19 > URL: https://jira.jboss.org/jira/browse/TEIID-19 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.1.0 > > > Defect Tracker #25002: In RuleCollapseSource, only one subquery per criteria predicate is supported. The association strategy should be generalized to support multiple subqueries and subqueries in the select clause as well. -- 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-127) Create a logging context specific to processing

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-127?page=com.atlassian.jira.plug... ] Work on TEIID-127 started by Steven Hawkins. > Create a logging context specific to processing > ----------------------------------------------- > > Key: TEIID-127 > URL: https://jira.jboss.org/jira/browse/TEIID-127 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.1.0 > > > Currently processing (com.metamatrix.query.processor) exceptions are mapped to the planner context. Either everything needs to be DQP or a specific context is needed. -- 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-19) Multiple subquery pushdown

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-19?page=com.atlassian.jira.plugi... ] Steven Hawkins updated TEIID-19: -------------------------------- Fix Version/s: 6.1.0 (was: 6.x) Affects Version/s: 6.0.0 (was: 6.x) > Multiple subquery pushdown > -------------------------- > > Key: TEIID-19 > URL: https://jira.jboss.org/jira/browse/TEIID-19 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.1.0 > > > Defect Tracker #25002: In RuleCollapseSource, only one subquery per criteria predicate is supported. The association strategy should be generalized to support multiple subqueries and subqueries in the select clause as well. -- 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-19) Multiple subquery pushdown

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-19?page=com.atlassian.jira.plugi... ] Steven Hawkins reassigned TEIID-19: ----------------------------------- Assignee: Steven Hawkins > Multiple subquery pushdown > -------------------------- > > Key: TEIID-19 > URL: https://jira.jboss.org/jira/browse/TEIID-19 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Optional > Fix For: 6.1.0 > > > Defect Tracker #25002: In RuleCollapseSource, only one subquery per criteria predicate is supported. The association strategy should be generalized to support multiple subqueries and subqueries in the select clause as well. -- 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-487) Clicking on console - MembershipDomainProviders causes server exception that it could determine role for method

by Van Halbert (JIRA)

Clicking on console - MembershipDomainProviders causes server exception that it could determine role for method --------------------------------------------------------------------------------------------------------------- Key: TEIID-487 URL: https://jira.jboss.org/jira/browse/TEIID-487 Project: Teiid Issue Type: Bug Components: Console, Server Affects Versions: 6.1.0 Reporter: Van Halbert Assignee: Steven Hawkins Clicking on console - MembershipDomainProviders causes server exception that it could determine role for method: Could not determine roles allowed for admin method at com.metamatrix.common.comm.platform.socket.server.AdminAuthorizationInterceptor.invoke(AdminAuthorizationInterceptor.java:95) at $Proxy26.getDomainNames(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.metamatrix.common.comm.platform.socket.server.ServerWorkItem.run(ServerWorkItem.java:100) at com.metamatrix.common.queue.WorkerPoolFactory$StatsCapturingSharedThreadPoolExecutor$1.run(WorkerPoolFactory.java:211) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:637) -- 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

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-489) SQLXML values should be bind variables

by Steven Hawkins (JIRA)

SQLXML values should be bind variables -------------------------------------- Key: TEIID-489 URL: https://jira.jboss.org/jira/browse/TEIID-489 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 6.1.0 SQLXML should not be pushed to the source as a literal value, instead it should be a bound value. -- 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] Commented: (TEIID-244) Salesforce Connector should offer the abilty to query about object deletions.

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-244?page=com.atlassian.jira.plug... ] John Doyle commented on TEIID-244: ---------------------------------- The connector should also be able to call the getUpdated operation as well. The combination of getDeleted and getUpdated will allow uses to maintain their local copy of SF data. > Salesforce Connector should offer the abilty to query about object deletions. > ----------------------------------------------------------------------------- > > Key: TEIID-244 > URL: https://jira.jboss.org/jira/browse/TEIID-244 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: John Doyle > Fix For: 6.1.0 > > > Genentech wants to materialize lots of SalesForce data in Oracle, to speed up their reporting query times. It makes a significant difference because SFDC does not support joins, whereas Oracle does. Wanting the best of both worlds, they also want the data to be as fresh as possible -- ideally, the mat views would be no more than 10 minutes out-of-sync with the live data. > The amount of data in SalesForce already takes 20+ minutes to cache, and it will slowly grow over time. So, the current materialization process will not meet the cache coherence (freshness) requirement, since the data will be stale by the time the staging table is populated and swapped in. > How would you speed it up? > .......response.... > I actually put together a custom materialization script > (attached,with doc and sample config file) for Credit Suisse for doing > these sorts of partial refreshes. It is Oracle-specific, but since > that is what you are doing too it should work for you too. > However, the use case at Credit Suisse was for doing these partial > refreshes nightly, with full refreshes done weekly. There is (just as > with our standard materialization scripts) a short period (when the > table names are being swapped) when the materialization won't be stable > (queries could fail or return unexpected results). I don't know if > that makes it not suitable for doing 10 minute refreshes. > I would recommend instead using the materialization only for historical > data (from overnight materialization run), and unioning it to the live > data for the newer stuff. That is, query SFDC only for data where > createdDate or LastModifiedDate = today, and union that with the > current data. Two issues you'd need to deal with in your logic: > -if the same record is retrieved from both sources (meaning it was an > existing record that had been modified today), the historical record > should be discarded in favor of the live one. > -deleted records - how to detect records that were deleted today? If > you could ask SFDC exactly what was deleted today that would be great, > but that is probably wishful thinking. So failing that you would need > to ask SFDC for the keys for all live records, and then discard from > the historical data any records with keys not on that list. Or, you > could just live with having the deleted records in the view for an > extra day... -- 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-244) Salesforce Connector should offer the abilty to query about object deletions.

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-244?page=com.atlassian.jira.plug... ] John Doyle updated TEIID-244: ----------------------------- Fix Version/s: 6.1.0 (was: 6.2.0) > Salesforce Connector should offer the abilty to query about object deletions. > ----------------------------------------------------------------------------- > > Key: TEIID-244 > URL: https://jira.jboss.org/jira/browse/TEIID-244 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: John Doyle > Fix For: 6.1.0 > > > Genentech wants to materialize lots of SalesForce data in Oracle, to speed up their reporting query times. It makes a significant difference because SFDC does not support joins, whereas Oracle does. Wanting the best of both worlds, they also want the data to be as fresh as possible -- ideally, the mat views would be no more than 10 minutes out-of-sync with the live data. > The amount of data in SalesForce already takes 20+ minutes to cache, and it will slowly grow over time. So, the current materialization process will not meet the cache coherence (freshness) requirement, since the data will be stale by the time the staging table is populated and swapped in. > How would you speed it up? > .......response.... > I actually put together a custom materialization script > (attached,with doc and sample config file) for Credit Suisse for doing > these sorts of partial refreshes. It is Oracle-specific, but since > that is what you are doing too it should work for you too. > However, the use case at Credit Suisse was for doing these partial > refreshes nightly, with full refreshes done weekly. There is (just as > with our standard materialization scripts) a short period (when the > table names are being swapped) when the materialization won't be stable > (queries could fail or return unexpected results). I don't know if > that makes it not suitable for doing 10 minute refreshes. > I would recommend instead using the materialization only for historical > data (from overnight materialization run), and unioning it to the live > data for the newer stuff. That is, query SFDC only for data where > createdDate or LastModifiedDate = today, and union that with the > current data. Two issues you'd need to deal with in your logic: > -if the same record is retrieved from both sources (meaning it was an > existing record that had been modified today), the historical record > should be discarded in favor of the live one. > -deleted records - how to detect records that were deleted today? If > you could ask SFDC exactly what was deleted today that would be great, > but that is probably wishful thinking. So failing that you would need > to ask SFDC for the keys for all live records, and then discard from > the historical data any records with keys not on that list. Or, you > could just live with having the deleted records in the view for an > extra day... -- 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-393) The Salesforce connector must be able to query about deleted SF objects.

by John Doyle (JIRA)

The Salesforce connector must be able to query about deleted SF objects. ------------------------------------------------------------------------ Key: TEIID-393 URL: https://jira.jboss.org/jira/browse/TEIID-393 Project: Teiid Issue Type: Feature Request Components: Salesforce Connector Reporter: John Doyle Assignee: John Doyle In order to make staging a local copy of SF data a viable solution, a customer has requested that the connector be able to report on deleted SF objects. The getDeleted cals in the SF API exists for this purpose. -- 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

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2009