July 2013 - teiid-issues - Jboss List Archives

[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 updated TEIID-2035: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=985576, https://bugzilla.redhat.com/show_bug.cgi?id=985578 (was: https://bugzilla.redhat.com/show_bug.cgi?id=985576) > 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

11 years, 5 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 updated TEIID-2035: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=985576 > 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

11 years, 5 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: --------------------------------------- A little more on this from an email: Depending upon the point of view TEIID-2578 has 1 or 2 responsibilities. The primary responsibility is to add (and possibly drop) a table/view/procedure to an existing Teiid schema with the corresponding update to the metadata repository. This is similar to the "CREATE FOREIGN TEMPORARY TABLE ... " feature except that the actual schema object is modified. This has implications wrt the visibility of the change and transactions and the caching of system schema entries (in the pg metadata layer for instance). Drop also requires a lot of book keeping to make sure that we're not breaking existing views or relationships. The other responsibility at least with tying this to materialization is the corresponding creation on the source of a particular table (procedures would require additional metadata) - but this is really not required by the first feature which is just to manipulate our metadata. Source creation of course has a lot of considerations in terms of ddl generation, creation of indexes, etc. It's conceivable that for materialized views this could be metadata driven to some degree. We/designer can associate ddl scripts with extension metadata (create-ddl, truncate-ddl, postload-ddl, etc.) on the view that is marked as materialized with the ability to run the ddl via the native procedure. That coupled with some notion of a state table would give us the ability to control implicit creation of the tables on the source. Whether we have a corresponding Teiid schema entry for the table is really up to the design of the feature. Some may want the materialized tables to effectively be hidden (which isn't currently possible as we require a reference to a source table), while others may want direct access even via Teiid for more complicated control over refresh. > 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2579) Have SSL connector support for plaintext passwords

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2579?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-2579. --------------------------------- Resolution: Done Added capability to express both as expressions and as well as cleartext for SSL based passwords > Have SSL connector support for plaintext passwords > -------------------------------------------------- > > Key: TEIID-2579 > URL: https://issues.jboss.org/browse/TEIID-2579 > Project: Teiid > Issue Type: Quality Risk > Affects Versions: 8.4 > Reporter: Graeme Gillies > Assignee: Ramesh Reddy > Fix For: 8.4.1, 8.5 > > > Hi, > At the moment the ssl configuration on the teiid jdbc and odbc connectors only supports keeping the keystore password in jboss vault. Can it please also support plain text passwords, and the documentation be updated to reflect this (at the moment the docs are incorrect as they have no mention of vault). > Regards, > Graeme -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2555) Support pushdown of entire dependent joins

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2555?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2555: --------------------------------------- The initial commit has been corrected and trivial scenarios have been verified end-to-end against oracle. However a lot of testing will be needed to validate this for basically all types against all possible supported sources: DB2, Derby, H2, HSQL (2.0+), MySQL, Oracle, PostgreSQL, SQLServer, Sybase The feature is safe-guarded - it has to be specifically enabled via the makedep join hint and requires the translator to have enableDependentJoins set. With further testing we can begin to relax these conditions and/or add additional capabilities to ensure that the independent side of the relation will be correctly handled. As mentioned earlier at some point the full and key set pushdown handling may be consolidated further. The full pushdown style is a little easier to implement (the method in JDBCQueryExecution is about half as long) - but using the join form for the key pushdown requires that the independent set is distinct (which we are now ensuring). However in the future there are some instances where the notion of a semi-join may be more appropriate and the current 8.5 will basically work in 8.4.1 should a backport be necessary. > Support pushdown of entire dependent joins > ------------------------------------------ > > Key: TEIID-2555 > URL: https://issues.jboss.org/browse/TEIID-2555 > Project: Teiid > Issue Type: Sub-task > Components: Connector API, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.5 > > > If the data volume is not too large then in many circumstances pushing down the entire independent side of the join to perform the entire join at the source can enhance performance. > This would likely be built upon TEIID-2249 to make use of a make dep hint option. It would also likely be an expansion of the common table pushdown logic - but will require more extensive planning changes as the default logic is geared toward only the equi-join columns. > It has also been requested that the default preference for pushdown be based upon the estimated data width. > There is an issue with the form of the plan as with the existing logic it would be nearly impossible to back out of the decision to perform the full pushdown (which is why a hint is initially preferable). -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2585) Update query metadata interface for update to teiid 8.5 interface

by Barry LaFond (JIRA)

Barry LaFond created TEIID-2585: ----------------------------------- Summary: Update query metadata interface for update to teiid 8.5 interface Key: TEIID-2585 URL: https://issues.jboss.org/browse/TEIID-2585 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Barry LaFond Assignee: Steven Hawkins Priority: Minor Fix For: 8.5 Parsed objects retain much of the original parse string, which is generally unnecessary on the server side. The use of output names should reduced to unnecessary memory consumption. -- 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

11 years, 5 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2577?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2577: --------------------------------------- > I still do not see the validity of this JIRA's issue in comparison to the Derby/H2 procedures, as I do not look at translation layer as execution of procedure construct, but as any arbitrary statement. Re-cursing back into Teiid engine for processing, seems bad not only in terms of processing, but also should expose same transactional issues as that of client layer. If this is right, I feel that it will (ab)used more for wrong reasons. I don't quite follow this. Imagine for a second that we did not have a virtual procedure language. How would someone go about writing a stored procedure? They would need access to some connection to execute a series of statements and other logic. The issue you may have with this is that it's being introduced at the translator layer rather than a specific api for "java stored procedures" - which is somewhat related to https://issues.jboss.org/browse/TEIID-147 although that could also be envisioned as still being user/designer driven with scriptable java. > 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2584) Add management features to materialization

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-2584: ----------------------------------- Summary: Add management features to materialization Key: TEIID-2584 URL: https://issues.jboss.org/browse/TEIID-2584 Project: Teiid Issue Type: Feature Request Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 8.5 Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache. External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen. -- 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

11 years, 5 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: ------------------------------------- You are proposing two different features here 1) Extend the Session scoped temp tables to the virtual procedures. 2) Ability to have anonymous procedure blocks both seem useful features, (1) being more immediately useful. I still do not see the validity of this JIRA's issue in comparison to the Derby/H2 procedures, as I do not look at translation layer as execution of procedure construct, but as any arbitrary statement. Re-cursing back into Teiid engine for processing, seems bad not only in terms of processing, but also should expose same transactional issues as that of client layer. If this is right, I feel that it will (ab)used more for wrong reasons. > 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2365) Reduce the usage of output names on the server side

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2365?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2365. ----------------------------------- Fix Version/s: 8.5 Resolution: Done Gave this a second look. We had already been using the string pool when setting output names, so that is why there didn't seem to be much difference with not setting the values altogether. However ultimately the change ended up being straight-forward by using the QueryMetadataInterface as the stateful mechanism to control whether output names are used. Also moved the resolver switch to find short names to be on the QMI rather than a static/threadlocal construct. > Reduce the usage of output names on the server side > --------------------------------------------------- > > Key: TEIID-2365 > URL: https://issues.jboss.org/browse/TEIID-2365 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Minor > Fix For: 8.5 > > > Parsed objects retain much of the original parse string, which is generally unnecessary on the server side. The use of output names should reduced to unnecessary memory consumption. -- 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

11 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2013