February 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Updated: (TEIID-233) Server should support JGroups communication over P2P

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-233?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-233: --------------------------------- Component/s: Server Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Affects: [Documentation (Ref Guide, User Guide, etc.), Release Notes] Complexity: Medium We shouldn't even need a GossipRouter since we know what the peer hosts are based upon the configuration. > Server should support JGroups communication over P2P > ---------------------------------------------------- > > Key: TEIID-233 > URL: https://jira.jboss.org/jira/browse/TEIID-233 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 6.0.0 > Reporter: Ramesh Reddy > Fix For: 6.1.0 > > > Currently Server only supports the JGroups over Multicast we need to support unicast protocol tool, with configuration. -- 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-235) ENHANCEMENT: function resolving should also consider return type

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-235?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-235: --------------------------------- Component/s: Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Affects: [Release Notes] Complexity: Medium > ENHANCEMENT: function resolving should also consider return type > ---------------------------------------------------------------- > > Key: TEIID-235 > URL: https://jira.jboss.org/jira/browse/TEIID-235 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.1.0 > > > Defect Tracker #24030: The use of PreparedStatements will cause functions to sometimes not resolve. However additional type information may be available if the function is used in comparison criteria. In this case the return type may also be used to match the signature of the function. -- 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-236) Procedural access pattern

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-236?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-236: --------------------------------- Component/s: Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Affects: [Documentation (Ref Guide, User Guide, etc.), Release Notes] Complexity: Medium > Procedural access pattern > ------------------------- > > Key: TEIID-236 > URL: https://jira.jboss.org/jira/browse/TEIID-236 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24374: It would be good to introduce a concept of a procedural access pattern (with designer support) that would capture the more restrictive semantics of procedure input criteria (=, in, and is null). -- 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-239) ENHANCEMENT: Costing beyond cardinality sould be propogated

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-239?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-239: --------------------------------- Component/s: Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Affects: [Release Notes] Complexity: Medium > ENHANCEMENT: Costing beyond cardinality sould be propogated > ----------------------------------------------------------- > > Key: TEIID-239 > URL: https://jira.jboss.org/jira/browse/TEIID-239 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24037: Currently values for ndv and nnv are recalculated at each plan node based upon the value at the physical layer. This is not a good estimate. Instead, these values should be propagated through the plan just like the cardinality and adjusted appropriately for join, unions, etc. It may also be good to allow the use of costing metadata on virtual layers. -- 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-238) ENHANCEMENT: performance of non-pushed dependent set criteria

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-238?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-238: --------------------------------- Original Estimate: 1 day Remaining Estimate: 1 day Component/s: Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Affects: [Release Notes] Complexity: Medium > ENHANCEMENT: performance of non-pushed dependent set criteria > ------------------------------------------------------------- > > Key: TEIID-238 > URL: https://jira.jboss.org/jira/browse/TEIID-238 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 6.1.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Defect Tracker #24299: Dependent set criteria that is not pushed below an access node has potentially bad performance implications. These nodes should either be removed or the evaluation of set criteria should be changed so that it does not need to be based upon iteration (such as a cached set of values). -- 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-241) Entitlements | Authorizations: add a "select all" option

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-241?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-241: --------------------------------- Component/s: Console Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Affects: [Documentation (Ref Guide, User Guide, etc.), Release Notes] Complexity: Low > Entitlements | Authorizations: add a "select all" option > --------------------------------------------------------- > > Key: TEIID-241 > URL: https://jira.jboss.org/jira/browse/TEIID-241 > Project: Teiid > Issue Type: Feature Request > Components: Console > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.1.0 > > > Defect Tracker #17626: On the Entitlements | Authorizations tab, it would be very useful to have > "select all" and "deselect all" options. > Right now, the user has to check each box individually - this is very cumbersome. > There can easily be 10s or 100s of models and tables in a model. > There should probably be a "select all" and "deselect all" option at the model-level, > and also at the table level. -- 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-243) Add the ability to support vararg functions

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-243?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-243: --------------------------------- Original Estimate: 2 days Remaining Estimate: 2 days Component/s: Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes] Complexity: Medium Priority: Minor (was: Major) Support would be needed by the designer as well. > Add the ability to support vararg functions > ------------------------------------------- > > Key: TEIID-243 > URL: https://jira.jboss.org/jira/browse/TEIID-243 > 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: 2 days > Remaining Estimate: 2 days > > It would be good to add resolving/metadata support for vararg functions. For example coalesce is a vararg function, and in general UDFs would benefit from utilizing varargs. -- 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-242) removing the Resource Connection Pool feature

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-242?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-242: --------------------------------- Component/s: Server Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes] (was: [Documentation (Ref Guide, User Guide, etc.)]) > removing the Resource Connection Pool feature > --------------------------------------------- > > Key: TEIID-242 > URL: https://jira.jboss.org/jira/browse/TEIID-242 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 6.0.0 > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 6.0.0 > > > removing the Resource Connection Pool administration option in the console for Westport. > Why? > 1. Because we developed 2 connection pooling frameworks in our product, and we don't need them both > 2. The Resource Connection Pool never became a feature of any value to the product, just overhead in the maintenance department > 3. Removing it from exposure will enable the server to eliminate multiple locations of connection properties (1. config.xml and 2. metamatrix.properties). The config.xml will no longer contain the ConnectionPool section. > 4. Remove any confusion in the console as to administrating the connection pool. > However, the monitoring of the Resource Connection Pool will still be seen in the console, so that monitoring of the connections can still be done (unless there's a decision to remove it also). -- 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-244) Salesforce Connector should offer the abilty to query about object deletions.

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-244?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-244: --------------------------------- Component/s: Salesforce Connector Fix Version/s: 6.1.0 Affects Version/s: 6.0.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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-245) Update costing metadata at runtime

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-245?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-245: --------------------------------- Component/s: Connector API Query Engine Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes] Complexity: High > Update costing metadata at runtime > ---------------------------------- > > Key: TEIID-245 > URL: https://jira.jboss.org/jira/browse/TEIID-245 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 6.1.0 > > > Defect Tracker #24584: Cost analysis should be both a design-time activity and scheduled/feed during runtime. -- 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