December 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Updated: (TEIID-189) Temp tables should maintain their costing metadata

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-189?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-189: --------------------------------- Fix Version/s: 7.1 (was: 7.0) > Temp tables should maintain their costing metadata > -------------------------------------------------- > > Key: TEIID-189 > URL: https://jira.jboss.org/jira/browse/TEIID-189 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 8.x > Reporter: Steven Hawkins > Priority: Optional > Fix For: 7.1 > > > Defect Tracker #24522: Temp table cardinality is currently only used for staging tables. It would also be generally useful for ad hoc queries to have the TempTableStoreImpl maintain the cardinality of the tables. Other costing information could actually be incorrect now (such as column min/max) depending upon what has been selected into a temp table. -- 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

14 years, 5 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: --------------------------------- Fix Version/s: 7.1 (was: 7.0) Priority: Minor (was: Major) pushing to 7.1. > 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 > Priority: Minor > Fix For: 7.1 > > > 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

14 years, 5 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-186) Expose catalog information and props in Connector API metadata [PEC]

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-186?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-186. ---------------------------------- Fix Version/s: 7.0 (was: 8.0) Resolution: Won't Fix The consensus is that a Designer model represents the source metadata, while a Teiid schema represents our local database perspective of accessing that data. The confusing part is that the reconciliation is happening implicitly. At runtime imported catalogs and schemas are not proper metadata artifacts and simply become part of the table name. The biggest issues with this approach are: 1. that no additional runtime metadata is available for imported catalogs/schemas (which resolves this issue) 2. the model allows for ambiguous fully qualified names, since we allow catalog and schema to be siblings and have the same name - however this is fairly contrived. 3. even though the proper group name as reported by our JDBC metadata may be something like catalog.schema.table, we still allow it to resolve against the partial name table (this has been noted in the reference manual). If we were being strict we would expect the user to quote the table name as "catalog.schema.table". > Expose catalog information and props in Connector API metadata [PEC] > -------------------------------------------------------------------- > > Key: TEIID-186 > URL: https://jira.jboss.org/jira/browse/TEIID-186 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 7.0 > > > Defect Tracker #20304: This request is to expose information on catalogs and schemas in relational models as separate entities and also to expose extension properties on those entities. Currently, only models and groups exist in runtime indexes and Connector API metadata and catalogs and schemas are just treated as namespace elements for groups. The XML Connector uses those catalogs and would like to store extension properties on them and retrieve those in the connector. -- 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

14 years, 5 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-249) Need well-known multi-payload container

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-249?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-249. ---------------------------------- Resolution: Won't Fix Without specifics, the current command payload feature seems sufficient. > Need well-known multi-payload container > --------------------------------------- > > Key: TEIID-249 > URL: https://jira.jboss.org/jira/browse/TEIID-249 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, JDBC Driver, Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 7.0 > > > Defect Tracker #21547: Currently it's up to users to build some container and extend connectors if they want to pass multiple payloads through the system. Would probably be better if we provided such a container, JDBC connectors were aware of it, and our commandPayload() functions worked with it. -- 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

14 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-199) Integration with JBoss Identity project

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-199?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-199: --------------------------------- Parent: TEIID-833 Issue Type: Sub-task (was: Feature Request) > Integration with JBoss Identity project > --------------------------------------- > > Key: TEIID-199 > URL: https://jira.jboss.org/jira/browse/TEIID-199 > Project: Teiid > Issue Type: Sub-task > Components: Server > Affects Versions: 6.0.0 > Reporter: Greg Haber > Assignee: Steven Hawkins > Fix For: 7.0 > > > There is a project underway, JBoss Identity (https://jira.jboss.org/jira/browse/JBID), that aims to provide common identity management support across many JBoss projects/products. According to the project leader's blog (http://anil-identity.blogspot.com/2008/12/federated-identity-support-with...), JBoss Application Server, JBoss Portal, JBoss SOA, JBoss Rules/Drools, and JBoss Seam are all on board with this approach. We should see if it makes sense for us to jump on the bandwagon. > The end goal of using the JBoss Identity stuff would be to replace the custom membership domain provider for authentication, and also to leverage it to provide SAML-based authorization for (ideally fine grained) access to Federate virtual databases. > SAML-based authorization has been a frequent request by prospects/customers for the closed source MetaMatrix product that is an ancestor to Federate. > I'm deliberately logging this one in the Federate project rather than the JBEDSP product JIRA since JBoss Identity itself is also still in project-only status. -- 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

14 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues December 2009