August 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-1092) Request to have variables at higher scopes

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1092?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-1092: ---------------------------------- Summary: Request to have variables at higher scopes (was: Request to have Global Variables) Description: Customer is requesting a global or session scoped variable. They want the variable to persist outside of one procedure to other spawned procedures and subsequent queries. (was: Customer is requesting a Global Variable. They want the variable to persist outside of one procedure to other spawned procedures and subsequent queries. ) > Request to have variables at higher scopes > ------------------------------------------ > > Key: TEIID-1092 > URL: https://issues.jboss.org/browse/TEIID-1092 > Project: Teiid > Issue Type: Feature Request > Components: Server > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.4 > > > Customer is requesting a global or session scoped variable. They want the variable to persist outside of one procedure to other spawned procedures and subsequent queries. -- 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-1092) Request to have Global Variables

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1092?page=com.atlassian.jira.plugin... ] Steven Hawkins reopened TEIID-1092: ----------------------------------- Changing the description/title. > Request to have Global Variables > -------------------------------- > > Key: TEIID-1092 > URL: https://issues.jboss.org/browse/TEIID-1092 > Project: Teiid > Issue Type: Feature Request > Components: Server > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.4 > > > Customer is requesting a Global Variable. They want the variable to persist outside of one procedure to other spawned procedures and subsequent queries. -- 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-2189) Can the behaviour of the || operator to use concat2 to mirror the oracle functionality be made configurable

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2189?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2189. ----------------------------------- Reasons against this: - it's non-ansi behavior - Oracle doesn't even guarantee this behavior in later version - addressing isn't straight-forward. We can just change the behavior of the function method. It would require us to internally differentiate between the || and the concat function and to ensure that all of the internal views (mostly in pg) use the concat function. So marking as won't fix unless there is an additional driver to add this behavior. > Can the behaviour of the || operator to use concat2 to mirror the oracle functionality be made configurable > ----------------------------------------------------------------------------------------------------------- > > Key: TEIID-2189 > URL: https://issues.jboss.org/browse/TEIID-2189 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector, Server > Affects Versions: 7.4.4 > Reporter: Van Halbert > Assignee: Steven Hawkins > Priority: Minor > > Is it possible to make configurable the ability to switch the behaviour of the || operator to use concat2 in order to mirror the oracle functionality. -- 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-2481) common table (with) push down improvements

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2481?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2481: ---------------------------------- Fix Version/s: 8.6 > common table (with) push down improvements > ------------------------------------------ > > Key: TEIID-2481 > URL: https://issues.jboss.org/browse/TEIID-2481 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.6 > > > The general strategy for with pushdown should better handle: > - a with clause that can be pushed against a source that does not support common table. If a single reference or some other sufficient condition is met then we should just inline the pushdown rather than inhibiting the whole query from pushing down. > - even if a source supports with pushdown, it may be more performant in some circumstances to inline the common table reference (such as only a single reference). This is complicated slightly by subqueries. > - alternatively in some situations even if a with clause can be pushed, it may be better to not perform the pushdown -e.g. two separate pushdown accesses to a common table that is expensive to compute (this may need to be hint driven). -- 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 updated TEIID-2577: ---------------------------------- Fix Version/s: 8.6 Component/s: Connector API Will look at providing something in 8.6. However the handling of session scoped temp tables will need to be thought out. The simplest approach is to allow them to escape, which would be consistent with the notion of local temporary tables on other dbms, but not consistent with Teiid (arguably Teiid's behavior is more about ensuring design-time validity). > Translator API to provide session backed connection > --------------------------------------------------- > > Key: TEIID-2577 > URL: https://issues.jboss.org/browse/TEIID-2577 > Project: Teiid > Issue Type: Feature Request > Components: Connector API > Reporter: Mark Addleman > Assignee: Steven Hawkins > Fix For: 8.6 > > > 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-2613) implicit rowcount handling

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2613?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2613. ----------------------------------- Resolution: Done Added more documentation and reset the rowcount value to 0 after non-update command statements. > implicit rowcount handling > -------------------------- > > Key: TEIID-2613 > URL: https://issues.jboss.org/browse/TEIID-2613 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.5 > > > We need to be more explicit about the internals of rowcount variable handling. Also the resolver doesn't make the rowcount variable visible to for each row plans. -- 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-2495) Detect situations in which intermediate updates are not needed such that the updates can be grouped

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2495?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2495: ---------------------------------- Attachment: teiid.patch Patch showing a sketch of update batching based upon the transaction. This would need refined (remove binding to allow for source batching, detect bulk, handling for generated keys, rowcount, etc.) and moved to the transactioncontext so that all updates could be trapped - otherwise a similar datamanager would be needed in ForEachRowPlan but both would miss lower level queries (such as actions triggered by matview queries). > Detect situations in which intermediate updates are not needed such that the updates can be grouped > --------------------------------------------------------------------------------------------------- > > Key: TEIID-2495 > URL: https://issues.jboss.org/browse/TEIID-2495 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 8.3 > Reporter: Jing Li > Assignee: Steven Hawkins > Fix For: 8.5 > > Attachments: teiid.patch > > > The default processing model is to simply perform the execution for each row, an enhancment would be required for Teiid to detect situations in which intermediate updates are not needed such that the updates can be grouped. -- 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-2613) implicit rowcount handling

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2613: ------------------------------------- Summary: implicit rowcount handling Key: TEIID-2613 URL: https://issues.jboss.org/browse/TEIID-2613 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.4.1, 8.5 We need to be more explicit about the internals of rowcount variable handling. Also the resolver doesn't make the rowcount variable visible to for each row plans. -- 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-2495) Detect situations in which intermediate updates are not needed such that the updates can be grouped

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2495?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2495. ----------------------------------- Resolution: Done Took the first path. Any single insert statement for each row plan will be converted into the equivalent single insert statement, which allows for batching or bulk passing to pass through if possible. However multiple inserts or complex processing will result in the default for each row behavior. A more general enhancement would look at for each row plans containing nothing but a series of update statements and turn that into a batched update plan. That too though is somewhat limiting, so I'd next pursue the general approach based upon the transaction layer, but that gets quite hairy - tracking updates by source, flushing when another access occurs, appropriately handling generated keys or update counts that are requested immediately, etc. Also elevated the internal notion of atomic to the entire for each row update, rather than for each row. A separate issue can be logged if needed for treating this in a more lax manner. > Detect situations in which intermediate updates are not needed such that the updates can be grouped > --------------------------------------------------------------------------------------------------- > > Key: TEIID-2495 > URL: https://issues.jboss.org/browse/TEIID-2495 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 8.3 > Reporter: Jing Li > Assignee: Steven Hawkins > Fix For: 8.5 > > > The default processing model is to simply perform the execution for each row, an enhancment would be required for Teiid to detect situations in which intermediate updates are not needed such that the updates can be grouped. -- 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-2495) Detect situations in which intermediate updates are not needed such that the updates can be grouped

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2495?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2495: --------------------------------------- There a a couple of paths here: * detect and rewrite the for each row sql (at least for internally generated procs we should do a better job) * Introduce sql server style instead of triggers, which could be used in addition to for each row and would be a straight-forward way to allow at least bulk insert handling. * Add a general update batching layer to the transaction handling logic The last of which is what I have been pursuing, but it gets quite complicated. Since we are also forcing the instead of blocks to be atomic, we should treat the whole update operation as atomic to prevent a transaction from being created for each row. It also implies that we may want to make the enforcement of atomic in the server somewhat lax to match the expectation when using autoCommitTxn=OFF or in embedded environments without a transaction manager. > Detect situations in which intermediate updates are not needed such that the updates can be grouped > --------------------------------------------------------------------------------------------------- > > Key: TEIID-2495 > URL: https://issues.jboss.org/browse/TEIID-2495 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 8.3 > Reporter: Jing Li > Assignee: Steven Hawkins > Fix For: 8.5 > > > The default processing model is to simply perform the execution for each row, an enhancment would be required for Teiid to detect situations in which intermediate updates are not needed such that the updates can be grouped. -- 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 August 2013