June 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5378) NPE when inserting into Global Temporary Table from a function or procedure

by Jan Stastny (JIRA)

Jan Stastny created TEIID-5378: ---------------------------------- Summary: NPE when inserting into Global Temporary Table from a function or procedure Key: TEIID-5378 URL: https://issues.jboss.org/browse/TEIID-5378 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 8.12.14.6_4 Reporter: Jan Stastny Assignee: Steven Hawkins Priority: Critical For following vdb: {code:xml} <vdb name="a" version="1"> <model name="vm1" type="VIRTUAL"> <metadata type="DDL"><![CDATA[ CREATE GLOBAL TEMPORARY TABLE teiidtemp(val integer) OPTIONS (UPDATABLE 'TRUE'); CREATE VIRTUAL FUNCTION f1() RETURNS string AS BEGIN INSERT INTO teiidtemp(val) VALUES (1); DECLARE string v1 = SELECT 'default'||COUNT(val) FROM teiidtemp; RETURN v1; END; CREATE VIRTUAL PROCEDURE p1() RETURNS (v1 string) AS BEGIN INSERT INTO teiidtemp(val) VALUES (1); SELECT 'default'||COUNT(val) FROM teiidtemp; END; ]]> </metadata> </model> </vdb> {code} The following errors occur when invoking procedure or function: # {code:sql}SELECT f1(){code} #* 15:49:17,608 WARN [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue14) TEIID30020 Processing exception for request 3rGTFUcDmmRP.0 'TEIID30328 Unable to evaluate f1(): TEIID30167 java.lang.NullPointerException'. Originally ExpressionEvaluationException TempTableDataManager.java:227. Enable more detailed logging to see the entire stacktrace. # {code:sql}SELECT a.v1 FROM (CALL p1()) a{code} #* 15:49:59,581 WARN [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue15) TEIID30020 Processing exception for request 3rGTFUcDmmRP.1 'TEIID30167 java.lang.NullPointerException'. Originally ProcedureErrorInstructionException TempTableDataManager.java:227. Enable more detailed logging to see the entire stacktrace. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5377) Type mismatch when issuing recursive common table expression query

by Andrej Šmigala (JIRA)

Andrej Šmigala created TEIID-5377: ------------------------------------- Summary: Type mismatch when issuing recursive common table expression query Key: TEIID-5377 URL: https://issues.jboss.org/browse/TEIID-5377 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 8.12.14.6_4 Reporter: Andrej Šmigala Assignee: Steven Hawkins Priority: Critical Running the following query: {code:sql} WITH tmp_cte(id, name, fk, fkname, lvl) AS (SELECT id, name, fk, cast(NULL as string) as fkname, 0 as lvl FROM SourceModel.cte_source WHERE fk IS NULL UNION ALL SELECT e.id, e.name, e.fk, ecte.name as fkname, lvl + 1 as lvl FROM SourceModel.cte_source AS e INNER JOIN tmp_cte AS ecte ON ecte.id = e.fk ) SELECT * FROM tmp_cte order by lvl {code} fails when run against an Oracle or MS SQL server (all versions). This issue only occurs with DV 6.4.3 CR1, not with previous versions. Probably caused by fix for TEIID-5313 h4. For MS SQL Server: * name column in source is defined as {{varchar(255)}} * name column in VDB is defined as {{string(4000)}} * query plan same before and after 6.4.3 * SOURCE SRC COMMAND before 6.4.3 (working): {code:sql}WITH tmp_cte (id, name, fk, fkname, lvl) AS (SELECT cast(g_0.id AS int), cast(g_0.name AS varchar(4000)), cast(g_0.fk AS int), cast(NULL AS varchar(4000)), cast(0 AS int) FROM cte_source g_0 WHERE g_0.fk IS NULL UNION ALL SELECT cast(g_0.id AS int), cast(g_0.name AS varchar(4000)), cast(g_0.fk AS int), cast(g_1.name AS varchar(4000)), cast((g_1.lvl + 1) AS int) FROM cte_source g_0, tmp_cte g_1 WHERE g_1.id = g_0.fk) SELECT g_0.id AS c_0, g_0.name AS c_1, g_0.fk AS c_2, g_0.fkname AS c_3, g_0.lvl AS c_4 FROM tmp_cte g_0 ORDER BY c_4{code} * SOURCE SRC COMMAND after 6.4.3 (not working, note the only difference is casting to nvarchar): {code:sql}WITH tmp_cte (id, name, fk, fkname, lvl) AS (SELECT cast(g_0.id AS int), cast(g_0.name AS varchar(4000)), cast(g_0.fk AS int), cast(NULL AS varchar(4000)), cast(0 AS int) FROM cte_source g_0 WHERE g_0.fk IS NULL UNION ALL SELECT cast(g_0.id AS int), cast(g_0.name AS varchar(4000)), cast(g_0.fk AS int), cast(g_1.name AS nvarchar(4000)), cast((g_1.lvl + 1) AS int) FROM cte_source g_0, tmp_cte g_1 WHERE g_1.id = g_0.fk) SELECT g_0.id AS c_0, g_0.name AS c_1, g_0.fk AS c_2, g_0.fkname AS c_3, g_0.lvl AS c_4 FROM tmp_cte g_0 ORDER BY c_4{code} h4. For Oracle: * name column in source is defined as {{varchar2(255)}} * name column in VDB is defined as {{string(4000)}} * query plan same before and after 6.4.3 * SOURCE SRC COMMAND before 6.4.3 (working): {code:sql}WITH tmp_cte (id, name, fk, fkname, lvl) AS (SELECT g_0.id, g_0.name, g_0.fk, NULL, 0 FROM cte_source g_0 WHERE g_0.fk IS NULL UNION ALL SELECT g_0.id, g_0.name, g_0.fk, g_1.name, (g_1.lvl + 1) FROM cte_source g_0, tmp_cte g_1 WHERE g_1.id = g_0.fk) SELECT g_0.id AS c_0, g_0.name AS c_1, g_0.fk AS c_2, g_0.fkname AS c_3, g_0.lvl AS c_4 FROM tmp_cte g_0 ORDER BY c_4{code} * SOURCE SRC COMMAND after 6.4.3 (not working, note the only difference is call to {{TO_NCHAR}}): {code:sql}WITH tmp_cte (id, name, fk, fkname, lvl) AS (SELECT g_0.id, g_0.name, g_0.fk, TO_NCHAR(NULL), 0 FROM cte_source g_0 WHERE g_0.fk IS NULL UNION ALL SELECT g_0.id, g_0.name, g_0.fk, g_1.name, (g_1.lvl + 1) FROM cte_source g_0, tmp_cte g_1 WHERE g_1.id = g_0.fk) SELECT g_0.id AS c_0, g_0.name AS c_1, g_0.fk AS c_2, g_0.fkname AS c_3, g_0.lvl AS c_4 FROM tmp_cte g_0 ORDER BY c_4{code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5373) Dependent set created from prepared IN predicate fails

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-5373?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-5373: --------------------------------- Fix Version/s: 8.12.14.6_4 > Dependent set created from prepared IN predicate fails > ------------------------------------------------------ > > Key: TEIID-5373 > URL: https://issues.jboss.org/browse/TEIID-5373 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.0, 10.3.2, 8.12.14.6_4 > > > If an IN predicate is used as a dependent set - for example when used as a procedural relational parameter or when it's too large and must be split among source commands - the dependentcriteriaprocessor will throw an assertionerror with "unknown predicate type" -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5374) Allow for non-virtual dependent joins to be created over unions

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5374?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5374. ----------------------------------- Fix Version/s: 10.3.2 10.2.3 Resolution: Done Corrected the issue with cost based union dependent join planning and the regression with TEIID-5020. Applied to 10.3 and 10.2 as well since it's possible for the regression to introduce incorrect results. > Allow for non-virtual dependent joins to be created over unions > ---------------------------------------------------------------- > > Key: TEIID-5374 > URL: https://issues.jboss.org/browse/TEIID-5374 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.0, 10.3.2, 10.2.3 > > > A simple structure like: > {code} > join > access > union > access > access > {code} > will reject creating a cost based dependent join over the union if the number of independent values seems too large for a virtual dependent join. > A related issue is that TEIID-5020 introduced a regression when creating a dependent join that is eventually pushed over a union below an access node: > {code} > dependent select > access > set op > .. > {code} > the logic attempts to move nested dependent select back above the access node - so that only a single dependent predicate exists - based upon the node that is created at a child. However if the child projects a literal into the dependent set criteria, then the result is invalid. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3750) Allow the parsing of an expression

by Jan Stastny (JIRA)

[ https://issues.jboss.org/browse/TEIID-3750?page=com.atlassian.jira.plugin... ] Jan Stastny commented on TEIID-3750: ------------------------------------ [~shawkins] What are the expectations here? On 8.12.14.6_4: # Teiid doesn't insert the default scalar value when defined on view or foreign table, but inserts null #* {code:sql}CREATE VIEW v1 ( e1 integer, e2 string NOT NULL DEFAULT 'default' ) OPTIONS (UPDATABLE TRUE) AS SELECT e1, e2 FROM g1;{code} # Teiid doesn't fail VDB deploy, when an expression is defined in DDL metadata when using the property "teiid_rel:default_handling" 'expression' on the column #* {code:sql}SET NAMESPACE 'http://www.teiid.org/ext/relational/2012' AS teiid_rel; CREATE VIRTUAL PROCEDURE get_default() RETURNS (v1 string) AS BEGIN SELECT 'default'; END CREATE FOREIGN TABLE g1( e1 integer, e2 string DEFAULT get_default() OPTIONS ("teiid_rel:default_handling" 'expression'));{code} # Teiid is able to import a default expression, but the property is not set in resulting DDL: #* {code:sql}CREATE FOREIGN TABLE g1 ( e1 integer OPTIONS (NAMEINSOURCE '"e1"', NATIVE_TYPE 'int4'), e2 string(15) NOT NULL DEFAULT 'timeofday()' OPTIONS (NAMEINSOURCE '"e2"', NATIVE_TYPE 'varchar') ) OPTIONS (NAMEINSOURCE '"public"."g1"', UPDATABLE TRUE);{code} # Teiid doesn't insert the value got by evaluation of the default expression, but inserts null > Allow the parsing of an expression > ---------------------------------- > > Key: TEIID-3750 > URL: https://issues.jboss.org/browse/TEIID-3750 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.14.6_4 > > > Now that we have an extension property, we could allow an expression to be used in parsing rather than just a string. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5376) Timezone handling discrepancies in MongoDB

by Jan Martiska (JIRA)

Jan Martiska created TEIID-5376: ----------------------------------- Summary: Timezone handling discrepancies in MongoDB Key: TEIID-5376 URL: https://issues.jboss.org/browse/TEIID-5376 Project: Teiid Issue Type: Bug Components: Misc. Connectors Reporter: Jan Martiska Assignee: Steven Hawkins Suppose this query against a MongoDB-backed VDB and you're running it in timezone UTC+1: {noformat} SELECT timestampvalue, HOUR(timestampvalue) AS TheHour FROM BQT1.SmallA WHERE (HOUR(timestampvalue) = 16); {noformat} If the database contains a timestamp '2000-01-01 16:00:00', you will get this row as result: ||timestampvalue||TheHour|| |2000-01-01 17:00:00|16| Looks like this is because the {{timestampvalue}} column is fully evaluated by Teiid and converted into the user's timezone, but the {{hour()}} call is pushed and evaluated by MongoDB and therefore evaluated as UTC and is not converted by Teiid to user's timezone. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5285) Add high-level feature for redirection of updates

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5285?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5285: ------------------------------------- [~shawkins] take look at the latest rendition with relationships, I only handled, 1-2-many in the example, but I intend to also cover 1-2-1 case similarly. If that looks good, then I will start writing the generation of the code based on metadata. Is there anything else you can think of? I am trying to keep them to a single database to avoid the use of XA transactions, which at least first go should be fine IMO. > Add high-level feature for redirection of updates > ------------------------------------------------- > > Key: TEIID-5285 > URL: https://issues.jboss.org/browse/TEIID-5285 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine, Teiid Spring Boot > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 11.x > > Attachments: redirection-vdb.xml > > > In microservices testing it is desirable to test against production/live data but not commit any updates. We should offer a simple solution that can defined by extension metadata and enabled/disabled by a feature flag. We may need to make simplifying assumptions about the scope (per session, per application, etc.) and durability of the updates. > Under the covers this will be achieved by using views, update triggers, and a store for the updates and when not enabled the expectation is that all operations should pass through. However the application will be limited to using Teiid SQL and will be required to use the Teiid or pg driver, or Teiid spring boot. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5285) Add high-level feature for redirection of updates

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5285?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-5285: -------------------------------- Attachment: redirection-vdb.xml > Add high-level feature for redirection of updates > ------------------------------------------------- > > Key: TEIID-5285 > URL: https://issues.jboss.org/browse/TEIID-5285 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine, Teiid Spring Boot > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 11.x > > Attachments: redirection-vdb.xml > > > In microservices testing it is desirable to test against production/live data but not commit any updates. We should offer a simple solution that can defined by extension metadata and enabled/disabled by a feature flag. We may need to make simplifying assumptions about the scope (per session, per application, etc.) and durability of the updates. > Under the covers this will be achieved by using views, update triggers, and a store for the updates and when not enabled the expectation is that all operations should pass through. However the application will be limited to using Teiid SQL and will be required to use the Teiid or pg driver, or Teiid spring boot. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5375) limit pushing should be considered prior to dependent join planning

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-5375: ------------------------------------- Summary: limit pushing should be considered prior to dependent join planning Key: TEIID-5375 URL: https://issues.jboss.org/browse/TEIID-5375 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 11.0 In some situations such as a limit over a left outer join, the effect of the limit should be considered in the costing of the left hand side of the join - but is currently not since rule push limits is fired after rule choose dependent. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5374) Allow for non-virtual dependent joins to be created over unions

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5374?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5374: ---------------------------------- Description: A simple structure like: {code} join access union access access {code} will reject creating a cost based dependent join over the union if the number of independent values seems too large for a virtual dependent join. A related issue is that TEIID-5020 introduced a regression when creating a dependent join that is eventually pushed over a union below an access node: {code} dependent select access set op .. {code} the logic attempts to move nested dependent select back above the access node - so that only a single dependent predicate exists - based upon the node that is created at a child. However if the child projects a literal into the dependent set criteria, then the result is invalid. was: A simple structure like: join access union access access will reject creating a cost based dependent join over the union if the number of independent values seems too large for a virtual dependent join. > Allow for non-virtual dependent joins to be created over unions > ---------------------------------------------------------------- > > Key: TEIID-5374 > URL: https://issues.jboss.org/browse/TEIID-5374 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.0 > > > A simple structure like: > {code} > join > access > union > access > access > {code} > will reject creating a cost based dependent join over the union if the number of independent values seems too large for a virtual dependent join. > A related issue is that TEIID-5020 introduced a regression when creating a dependent join that is eventually pushed over a union below an access node: > {code} > dependent select > access > set op > .. > {code} > the logic attempts to move nested dependent select back above the access node - so that only a single dependent predicate exists - based upon the node that is created at a child. However if the child projects a literal into the dependent set criteria, then the result is invalid. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2018