November 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5552) Audit Logging for ODBC

by Chandra Akkinepalli (Jira)

Chandra Akkinepalli created TEIID-5552: ------------------------------------------ Summary: Audit Logging for ODBC Key: TEIID-5552 URL: https://issues.jboss.org/browse/TEIID-5552 Project: Teiid Issue Type: Enhancement Reporter: Chandra Akkinepalli Assignee: Steven Hawkins The teiid audit logging for ODBC transport type doesn't log the ip address/ server name of the client when there is load balancer handling the routing to the nodes. It prints the ip address of the load balancer. I would like to request to enhanced logging to provide the ip address of the client like JDBC transport. These details are available via adminshell getSessions() command , but not available in teiid-audit logs. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5530) common tables used in only 1 location which is a subquery still inlined

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5530?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5530. ----------------------------------- Resolution: Partially Completed Added a doc note about the inlining with correlated subqueries. > common tables used in only 1 location which is a subquery still inlined > ----------------------------------------------------------------------- > > Key: TEIID-5530 > URL: https://issues.jboss.org/browse/TEIID-5530 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > With a query such as: > with x as (select ...) > select (select ... from x where ...) from y > The x common table is inlined even though it may be less efficient for processing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5530) common tables used in only 1 location which is a subquery still inlined

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5530?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5530: --------------------------------------- There isn't a great way to address this with the current code structure. The inlining happens during rewrite before correlated references are generally set. I'll resolve this for now with a doc note. > common tables used in only 1 location which is a subquery still inlined > ----------------------------------------------------------------------- > > Key: TEIID-5530 > URL: https://issues.jboss.org/browse/TEIID-5530 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > With a query such as: > with x as (select ...) > select (select ... from x where ...) from y > The x common table is inlined even though it may be less efficient for processing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4498) Generalize subquery batch processing

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-4498?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4498: ---------------------------------- Fix Version/s: 12.0 (was: 12.x) I'll see if this can be addressed in 12.0. The first step is to generalize the unnesting that we do for subqueries in the where clause to other locations. For situations where that is not possible we can consider an optimization that would create a base common table, and common tables for each of the subqueries (similar to the logic that raised criteria in the xml processing logic). select (select ... ), (select ...), a, b ... from ... would become: with base as (select ... a, b ... from ...) sub1 as (select ... from ..., base where ... col = base.col, ...) sub2 as (select ... from ..., base where ... col = base.col, ...) select (select ... from sub1 where col = base.col), (select ... from sub2 where col = base.col) ... from base which means that after loading the base, we'll use that to drive the load of each of the sub query tables, > Generalize subquery batch processing > ------------------------------------ > > Key: TEIID-4498 > URL: https://issues.jboss.org/browse/TEIID-4498 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > For subqueries that cannot be unnested, but can be modified to project their correlation, we should have at least batch processing rather than the row by row default. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5542) XMLTable path assumptions

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5542?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5542. ----------------------------------- Resolution: Done Added org.teiid.relativeXPath to control the behavior of path values begining with / or //. The default for now will remain the legacy behavior. > XMLTable path assumptions > ------------------------- > > Key: TEIID-5542 > URL: https://issues.jboss.org/browse/TEIID-5542 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > By the spec, and for example with Postgresql, a column PATH that begins with / or // is not relative to the context item. Teiid modeled its initial implementation on Oracle where that is the case. For greater compliance we should add an option to change the handling to be spec compliant. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5551) Inconsistency with document projection

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5551?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5551: ---------------------------------- The logic here no opts to providing the full string value - which could be a breaking change for some scenarios - so it may need a flag for 11.2.x. > Inconsistency with document projection > -------------------------------------- > > Key: TEIID-5551 > URL: https://issues.jboss.org/browse/TEIID-5551 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0, 11.2.1 > > > When using the xml type for a given column the entire subtree is returned - which is universally the expected behavior. If projection is used and another type is used, then only local node text will be considered. If projection is disabled, all of the descendant text is considered. > Based upon our initial consistency with oracle, we should consider all of the descendant text. > for example: > Select * From XmlTable('/root' Passing xmlparse(document '<root><def><test1>10</test1><test1>20</test1></def><abc>22</abc></root>') > Columns b varchar(40) Path 'def') xx > should return 1020. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5551) Inconsistency with document projection

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5551: ------------------------------------- Summary: Inconsistency with document projection Key: TEIID-5551 URL: https://issues.jboss.org/browse/TEIID-5551 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 12.0, 11.2.1 When using the xml type for a given column the entire subtree is returned - which is universally the expected behavior. If projection is used and another type is used, then only local node text will be considered. If projection is disabled, all of the descendant text is considered. Based upon our initial consistency with oracle, we should consider all of the descendant text. for example: Select * From XmlTable('/root' Passing xmlparse(document '<root><def><test1>10</test1><test1>20</test1></def><abc>22</abc></root>') Columns b varchar(40) Path 'def') xx should return 1020. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5542) XMLTable path assumptions

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5542?page=com.atlassian.jira.plugin... ] Work on TEIID-5542 started by Steven Hawkins. --------------------------------------------- > XMLTable path assumptions > ------------------------- > > Key: TEIID-5542 > URL: https://issues.jboss.org/browse/TEIID-5542 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > By the spec, and for example with Postgresql, a column PATH that begins with / or // is not relative to the context item. Teiid modeled its initial implementation on Oracle where that is the case. For greater compliance we should add an option to change the handling to be spec compliant. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5538) Option nocache does not apply to subqueries

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5538?page=com.atlassian.jira.plugin... ] Work on TEIID-5538 started by Steven Hawkins. --------------------------------------------- > Option nocache does not apply to subqueries > ------------------------------------------- > > Key: TEIID-5538 > URL: https://issues.jboss.org/browse/TEIID-5538 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > When specifying "option nocache" or a related option, those hints are only propagated through view layers - but not to sub-queries. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5546) Namespace resolution on vdb level

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5546?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5546. ----------------------------------- Resolution: Done The parser was not passing the namespace container for the current database to the property parsing logic. That has been updated for all the ddl paths. > Namespace resolution on vdb level > --------------------------------- > > Key: TEIID-5546 > URL: https://issues.jboss.org/browse/TEIID-5546 > Project: Teiid > Issue Type: Feature Request > Affects Versions: 10.3.5 > Reporter: Bram Gadeyne > Assignee: Steven Hawkins > Priority: Major > Labels: ddl, namespace, rest, teiid > Fix For: 12.0, 11.2.1 > > > This does work in a DDL based vdb: > {code:sql} > create database vdb version '1.2.0' OPTIONS ("{http://teiid.org/rest}auto-generate" 'true'); > {code} > This doesn't: > {code:sql} > create database vdb version '1.2.0' OPTIONS ("teiid_rest:auto-generate" 'true'); > {code} > It would be nice if the namespace resolution also worked at vdb level. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues November 2018