July 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2578) Provide API to add schema elements at translator layer

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2578: ------------------------------------- I see the divide now. Yes this feature is not really required for materialization TEIID-2584. > Provide API to add schema elements at translator layer > ------------------------------------------------------ > > Key: TEIID-2578 > URL: https://issues.jboss.org/browse/TEIID-2578 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 8.5 > > > Currently the translator API is can expose the source schema they represent, however there are no facilities to create the schema elements like > * table > * procedure > the function support is available, but this needs be re-factored under this interface (may be this can be a follow on task) > Using this feature, query engine should be able to ad-hoc create tables or procedures. The motivation for the feature is to provide a more comprehensive materialization feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-196) Support creation of temp tables on physical sources.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-196?page=com.atlassian.jira.plugin.... ] Steven Hawkins commented on TEIID-196: -------------------------------------- With TEIID-2558 JDBC translators can create temporary tables for dependent join pushdown, but I'm hesitant to tie that to this feature since that usage is more focused and there is no need for higher level connection management - unless a real source table is created, the same connection must be reused to maintain access to the temporary table. > Support creation of temp tables on physical sources. > ---------------------------------------------------- > > Key: TEIID-196 > URL: https://issues.jboss.org/browse/TEIID-196 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Affects Versions: 6.0.0 > Reporter: Ken Johnson > Assignee: Steven Hawkins > Fix For: 8.3 > > > This is a multi-part request. > First, the system should support creation of temporary tables using a physical backing store rather than buffer manger. Given multi-pass SQL's heavy use of temp tables, buffer manager can easily be overloaded with large interim results stored in temp tables. > Second, this should be a user-configurable behavior. For example, user might be able to choose a system-level or session-level default from among: > -- memory/cache > -- a source represented by a connector binding > -- a distinct temp source defined with it's own connection parameters (possibly another schema in the repository DB instance) > Ideally default selectoin should be override-able at temp table creation time through a DDL extension > In the case where multiple temp tables have been created on a source via connector, the query planner should recognize this and leverage pushdown to the temp store when later query passes access multiple temp tables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2587) source hint placed in with clause

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2587?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2587. ----------------------------------- Resolution: Done Ensured the source hint is added to the main select > source hint placed in with clause > --------------------------------- > > Key: TEIID-2587 > URL: https://issues.jboss.org/browse/TEIID-2587 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.5 > > > The sql conversion visitor is placing the source hint in the first select, which can be in the with clause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2587) source hint placed in with clause

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2587: ------------------------------------- Summary: source hint placed in with clause Key: TEIID-2587 URL: https://issues.jboss.org/browse/TEIID-2587 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 7.7 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.4.1, 8.5 The sql conversion visitor is placing the source hint in the first select, which can be in the with clause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2578) Provide API to add schema elements at translator layer

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2578: --------------------------------------- > I was only thinking to expose this layer to engine to begin with, so client based requests are not involved to modify the vdb metadata. But that could be an addition. My initial comments are based off of the title, which implies runtime manipulation of Teiid schema entries. That in and of itself is a feature and if possible via a translator should be exposed via statements. Maybe it would help to clarify the flow for materialization metadata. Here are three scenarios: 1. The current internal approach. The view metadata only is known to Teiid and we create an internal "global" materialized temporary table based upon the metadata. The temporary table is not explicitly part of any Teiid schema and can only be referenced through the materialized view and through admin procedures. 2. The current external approach. The view metadata is known to Teiid but it must also reference another table that is presumed to contain the materialized results - we do not know how the Teiid metadata entry was created or how the corresponding source materialized table was created. 3. What I think you're pursuing. The view metadata only is known to Teiid but the view must also reference a source on which to materialize. From here we must fill in all the details of how the source materialized table is created and what metadata Teiid uses to represent it. Related to creating Teiid schema entries, if we follow the approach of #1 then there is no need to alter Teiid schema's at runtime. So to clarify I'd like to: * decouple the notion of adding schema entries from materialization. * start with the most simplistic approach to 2/3 by offing the ability to create a materialization model (similar to the old MMX approach which can be done somewhat like the Hibernate temp logic). This would be generated either at or before deploy time and obviates the need to alter Teiid schemas at runtime. From there the real meat of the issue is TEIID-2584. For example as mentioned above if we want to offer the ability to manage and tweak the ddl that could be done via extension metadata - for any high-end usage no one will rely on auto generated ddl since they will need to fill in details such as the tablespace, alternative index types (hash, bitmap), additional columns for incremental update, etc. TEIID-2584 is also complicated by source permissions at least in terms of creation - that was side-stepped by MMX and not a concern with the internal logic. > Provide API to add schema elements at translator layer > ------------------------------------------------------ > > Key: TEIID-2578 > URL: https://issues.jboss.org/browse/TEIID-2578 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 8.5 > > > Currently the translator API is can expose the source schema they represent, however there are no facilities to create the schema elements like > * table > * procedure > the function support is available, but this needs be re-factored under this interface (may be this can be a follow on task) > Using this feature, query engine should be able to ad-hoc create tables or procedures. The motivation for the feature is to provide a more comprehensive materialization feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2067) Global temporary tables

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2067?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2067: --------------------------------------- Based upon our current metadata system this could be implemented as explicitly declared global temporary tables (just like any other schema object) and Teiid would maintain the associated semantics - the table definition is globally available but that each session would have separate data. >From the request however it seems that what your looking for is really just the ability to create "real" tables that have their definition and data available to all sessions. This could fall under TEIID-2578 or a related issue. > Global temporary tables > ----------------------- > > Key: TEIID-2067 > URL: https://issues.jboss.org/browse/TEIID-2067 > Project: Teiid > Issue Type: Feature Request > Affects Versions: 7.7 > Reporter: Mark Addleman > Assignee: Steven Hawkins > > Currently, temp tables are scoped to the teiid session (eg, jdbc connection) that created them. I would like temp tables visible to all sessions. It is acceptable and even desirable that temp tables use an external database a la external materialization. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2035) DeleteDataSource method on Admin API does not completely delete the Connection Factory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2035?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2035: ------------------------------------------------ Alessio Soldano <asoldano(a)redhat.com> made a comment on [bug 985576|https://bugzilla.redhat.com/show_bug.cgi?id=985576] Not sure why this has been assigned to me... > DeleteDataSource method on Admin API does not completely delete the Connection Factory > -------------------------------------------------------------------------------------- > > Key: TEIID-2035 > URL: https://issues.jboss.org/browse/TEIID-2035 > Project: Teiid > Issue Type: Bug > Components: AdminApi > Affects Versions: 8.0 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > > ConnectionFactory requires a two step creation process > 1) create the resource-adaptor section > 2) connection factory section > The delete is removing the (2) and not (1). Thus any subsequent creates using the same name fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2586) foreign temporary table consistency

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2586: ------------------------------------- Summary: foreign temporary table consistency Key: TEIID-2586 URL: https://issues.jboss.org/browse/TEIID-2586 Project: Teiid Issue Type: Quality Risk Components: Query Engine Affects Versions: 8.3 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.4.1, 8.5 When creating a foreign temporary table the local keyword is omitted. This was done to cut out some of the verboseness, however it's not consistent with non-foreign tables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2577) Translator API to provide session backed connection

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2577?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2577: ------------------------------------- Yes, my concern is about introducing this at translator layer. If this was part of java procedure API, then it is at the engine level, it will be analogous to virtual procedures. > Translator API to provide session backed connection > --------------------------------------------------- > > Key: TEIID-2577 > URL: https://issues.jboss.org/browse/TEIID-2577 > Project: Teiid > Issue Type: Feature Request > Reporter: Mark Addleman > Assignee: Steven Hawkins > > Provide an API (probably from an ExecutionContext) to obtain a JDBC connection to the same Teiid instance under the client's session. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2578) Provide API to add schema elements at translator layer

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2578: ------------------------------------- I was only thinking to expose this layer to engine to begin with, so client based requests are not involved to modify the vdb metadata. But that could be an addition. With this available to the engine, then use for materialization as source table creation. I understand what you are saying about the ddl generation and creation of indexes, but for that I do not want to take extension metadata from designer, I was thinking I would rather use hibernate facilities for JDBC (like how you did for the temptable), and leave up to the translator implementation for supporting other source types. So, effectively I would like to treat matviews as always external, if the source is missing route to a known internal translator, which is effectively the current global temp table store or could be a java db. There is whole lot of code in temptable/materialization, trying to understand it first. > Provide API to add schema elements at translator layer > ------------------------------------------------------ > > Key: TEIID-2578 > URL: https://issues.jboss.org/browse/TEIID-2578 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 8.5 > > > Currently the translator API is can expose the source schema they represent, however there are no facilities to create the schema elements like > * table > * procedure > the function support is available, but this needs be re-factored under this interface (may be this can be a follow on task) > Using this feature, query engine should be able to ad-hoc create tables or procedures. The motivation for the feature is to provide a more comprehensive materialization feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2013