January 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3297) Possible NPE in WSConnectionImpl

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3297?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-3297. --------------------------------- Resolution: Duplicate Issue TEIID-2956 > Possible NPE in WSConnectionImpl > -------------------------------- > > Key: TEIID-3297 > URL: https://issues.jboss.org/browse/TEIID-3297 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.4 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 8.10 > > > {code} > ArrayList contentTypes = (ArrayList)this.responseContext.get("content-type"); //$NON-NLS-1$ > String contentType = contentTypes != null ? (String)contentTypes.get(0):"application/octet-stream"; //$NON-NLS-1$ > {code} > Looking at http://stackoverflow.com/questions/20392345/is-content-type-http-header-a... it is not always required but recommended. In the DV it is more required because, based on this it will to build the object of that type. What is missing is NPE handling there. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3298) invokeHttp procedure should support returning HTTP Response Code

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-3298: ----------------------------------- Summary: invokeHttp procedure should support returning HTTP Response Code Key: TEIID-3298 URL: https://issues.jboss.org/browse/TEIID-3298 Project: Teiid Issue Type: Enhancement Components: Misc. Connectors Affects Versions: 8.4 Reporter: Ramesh Reddy Assignee: Steven Hawkins Currently WS Translator supplied "invokeHttp" procedure only returns the result and as well as the content-type. It should also return response code. It may be useful to check if there is any other return parameters can be useful too. Like cookie etc. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3297) Possible NPE in WSConnectionImpl

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3297?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-3297: -------------------------------- Description: {code} ArrayList contentTypes = (ArrayList)this.responseContext.get("content-type"); //$NON-NLS-1$ String contentType = contentTypes != null ? (String)contentTypes.get(0):"application/octet-stream"; //$NON-NLS-1$ {code} Looking at http://stackoverflow.com/questions/20392345/is-content-type-http-header-a... it is not always required but recommended. In the DV it is more required because, based on this it will to build the object of that type. What is missing is NPE handling there. was: {code} ArrayList contentTypes = (ArrayList)this.responseContext.get("content-type"); //$NON-NLS-1$ String contentType = contentTypes != null ? (String)contentTypes.get(0):"application/octet-stream"; //$NON-NLS-1$ {code} Looking at http://stackoverflow.com/questions/20392345/is-content-type-http-header-a... it is not always required but recommended. In the DV it is more required because, based on this it will to build the object of that type. What is missing is NPE handling there. > Possible NPE in WSConnectionImpl > -------------------------------- > > Key: TEIID-3297 > URL: https://issues.jboss.org/browse/TEIID-3297 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.4 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 8.10 > > > {code} > ArrayList contentTypes = (ArrayList)this.responseContext.get("content-type"); //$NON-NLS-1$ > String contentType = contentTypes != null ? (String)contentTypes.get(0):"application/octet-stream"; //$NON-NLS-1$ > {code} > Looking at http://stackoverflow.com/questions/20392345/is-content-type-http-header-a... it is not always required but recommended. In the DV it is more required because, based on this it will to build the object of that type. What is missing is NPE handling there. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3297) Possible NPE in WSConnectionImpl

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-3297: ----------------------------------- Summary: Possible NPE in WSConnectionImpl Key: TEIID-3297 URL: https://issues.jboss.org/browse/TEIID-3297 Project: Teiid Issue Type: Bug Components: Misc. Connectors Affects Versions: 8.4 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 8.10 {code} ArrayList contentTypes = (ArrayList)this.responseContext.get("content-type"); //$NON-NLS-1$ String contentType = contentTypes != null ? (String)contentTypes.get(0):"application/octet-stream"; //$NON-NLS-1$ {code} Looking at http://stackoverflow.com/questions/20392345/is-content-type-http-header-a... it is not always required but recommended. In the DV it is more required because, based on this it will to build the object of that type. What is missing is NPE handling there. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables

by Salvatore R (JIRA)

[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ] Salvatore R updated TEIID-3296: ------------------------------- Description: The following two tables are defined in two different datasources (PostgreSQL and MySQL): {code:sql} CREATE TABLE "pg"."tx1" ( a varchar(2147483647), b varchar(2147483647), c integer, d integer, e integer ); CREATE INDEX tx1_b ON "pg"."tx1"(b); CREATE INDEX tx1_a ON "pg"."tx1"(a); CREATE INDEX tx1_e ON "pg"."tx1"(e); CREATE INDEX tx1_d ON "pg"."tx1"(d); CREATE INDEX tx1_c ON "pg"."tx1"(c); CREATE TABLE "my"."tx2" ( a integer, b integer, c integer, d integer, e integer ); insert into tx1 VALUES(1,1,1,1,1) ; insert into tx1 VALUES(1,2,2,2,2) ; insert into tx1 VALUES(1,2,3,3,3) ; insert into tx1 VALUES(1,2,3,4,4) ; insert into tx1 VALUES(1,2,3,4,5) ; insert into tx2 VALUES(1,2,3,4,5) ; {code} Running the following query: {code:sql} select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e; {code} a wrong result is returned: ||a||b||c||d||e|| |1|2|2|2|2| |1|2|3|3|3| |1|2|3|4|4| If indexes are removed from the source table, the expected result is correctly returned: ||a||b||c||d||e|| |1|2|3|4|4| was: The following two tables are defined in two different datasources PostgreSQL and MySQL): {code:sql} CREATE TABLE "pg"."tx1" ( a varchar(2147483647), b varchar(2147483647), c integer, d integer, e integer ); CREATE INDEX tx1_b ON "pg"."tx1"(b); CREATE INDEX tx1_a ON "pg"."tx1"(a); CREATE INDEX tx1_e ON "pg"."tx1"(e); CREATE INDEX tx1_d ON "pg"."tx1"(d); CREATE INDEX tx1_c ON "pg"."tx1"(c); CREATE TABLE "my"."tx2" ( a integer, b integer, c integer, d integer, e integer ); insert into tx1 VALUES(1,1,1,1,1) ; insert into tx1 VALUES(1,2,2,2,2) ; insert into tx1 VALUES(1,2,3,3,3) ; insert into tx1 VALUES(1,2,3,4,4) ; insert into tx1 VALUES(1,2,3,4,5) ; insert into tx2 VALUES(1,2,3,4,5) ; {code} Running the following query: {code:sql} select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e; {code} a wrong result is returned: ||a||b||c||d||e|| |1|2|2|2|2| |1|2|3|3|3| |1|2|3|4|4| If indexes are removed from the source table, the expected result is correctly returned: ||a||b||c||d||e|| |1|2|3|4|4| > Some criteria are missing when indexes are used on the source tables > -------------------------------------------------------------------- > > Key: TEIID-3296 > URL: https://issues.jboss.org/browse/TEIID-3296 > Project: Teiid > Issue Type: Bug > Reporter: Salvatore R > Assignee: Steven Hawkins > > The following two tables are defined in two different datasources (PostgreSQL and MySQL): > {code:sql} > CREATE TABLE "pg"."tx1" > ( > a varchar(2147483647), > b varchar(2147483647), > c integer, > d integer, > e integer > ); > CREATE INDEX tx1_b ON "pg"."tx1"(b); > CREATE INDEX tx1_a ON "pg"."tx1"(a); > CREATE INDEX tx1_e ON "pg"."tx1"(e); > CREATE INDEX tx1_d ON "pg"."tx1"(d); > CREATE INDEX tx1_c ON "pg"."tx1"(c); > > CREATE TABLE "my"."tx2" > ( > a integer, > b integer, > c integer, > d integer, > e integer > ); > insert into tx1 VALUES(1,1,1,1,1) ; > insert into tx1 VALUES(1,2,2,2,2) ; > insert into tx1 VALUES(1,2,3,3,3) ; > insert into tx1 VALUES(1,2,3,4,4) ; > insert into tx1 VALUES(1,2,3,4,5) ; > insert into tx2 VALUES(1,2,3,4,5) ; > {code} > Running the following query: > {code:sql} > select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e; > {code} > a wrong result is returned: > ||a||b||c||d||e|| > |1|2|2|2|2| > |1|2|3|3|3| > |1|2|3|4|4| > If indexes are removed from the source table, the expected result is correctly returned: > ||a||b||c||d||e|| > |1|2|3|4|4| -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables

by Salvatore R (JIRA)

Salvatore R created TEIID-3296: ---------------------------------- Summary: Some criteria are missing when indexes are used on the source tables Key: TEIID-3296 URL: https://issues.jboss.org/browse/TEIID-3296 Project: Teiid Issue Type: Bug Reporter: Salvatore R Assignee: Steven Hawkins The following two tables are defined in two different datasources PostgreSQL and MySQL): {code:sql} CREATE TABLE "pg"."tx1" ( a varchar(2147483647), b varchar(2147483647), c integer, d integer, e integer ); CREATE INDEX tx1_b ON "pg"."tx1"(b); CREATE INDEX tx1_a ON "pg"."tx1"(a); CREATE INDEX tx1_e ON "pg"."tx1"(e); CREATE INDEX tx1_d ON "pg"."tx1"(d); CREATE INDEX tx1_c ON "pg"."tx1"(c); CREATE TABLE "my"."tx2" ( a integer, b integer, c integer, d integer, e integer ); insert into tx1 VALUES(1,1,1,1,1) ; insert into tx1 VALUES(1,2,2,2,2) ; insert into tx1 VALUES(1,2,3,3,3) ; insert into tx1 VALUES(1,2,3,4,4) ; insert into tx1 VALUES(1,2,3,4,5) ; insert into tx2 VALUES(1,2,3,4,5) ; {code} Running the following query: {code:sql} select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e; {code} a wrong result is returned: ||a||b||c||d||e|| |1|2|2|2|2| |1|2|3|3|3| |1|2|3|4|4| If indexes are removed from the source table, the expected result is correctly returned: ||a||b||c||d||e|| |1|2|3|4|4| -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3290) Auto generated REST WAR truncates the larger payloads

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3290?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-3290: -------------------------------- Summary: Auto generated REST WAR truncates the larger payloads (was: Auto generated REST WAR should support POST BODY as parameter) Affects Version/s: 8.4 > Auto generated REST WAR truncates the larger payloads > ----------------------------------------------------- > > Key: TEIID-3290 > URL: https://issues.jboss.org/browse/TEIID-3290 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.4 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > > Currently only query parameters are supported as the input parameters to the Teiid procedure in POST based call. > The POST BODY also needs to be supported to handle larger payloads in this situation as query parameters has size limitations. Currently string based query parameters are supported, but since they passed as is as strings on larger payloads the they will be subject 4000 string length restriction. > It should be possible to read metadata of the procedure and convert the string objects to respective objects before the query gets executed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3290) Auto generated REST WAR should support POST BODY as parameter

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3290?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-3290: -------------------------------- Issue Type: Bug (was: Enhancement) > Auto generated REST WAR should support POST BODY as parameter > ------------------------------------------------------------- > > Key: TEIID-3290 > URL: https://issues.jboss.org/browse/TEIID-3290 > Project: Teiid > Issue Type: Bug > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > > Currently only query parameters are supported as the input parameters to the Teiid procedure in POST based call. > The POST BODY also needs to be supported to handle larger payloads in this situation as query parameters has size limitations. Currently string based query parameters are supported, but since they passed as is as strings on larger payloads the they will be subject 4000 string length restriction. > It should be possible to read metadata of the procedure and convert the string objects to respective objects before the query gets executed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3290) Auto generated REST WAR should support POST BODY as parameter

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3290?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-3290: -------------------------------- Description: Currently only query parameters are supported as the input parameters to the Teiid procedure in POST based call. The POST BODY also needs to be supported to handle larger payloads in this situation as query parameters has size limitations. Currently string based query parameters are supported, but since they passed as is as strings on larger payloads the they will be subject 4000 string length restriction. It should be possible to read metadata of the procedure and convert the string objects to respective objects before the query gets executed. was: Currently only query parameters are supported as the input parameters to the Teiid procedure in POST based call. The POST BODY also needs to be supported to handle larger payloads in this situation as query parameters has size limitations. > Auto generated REST WAR should support POST BODY as parameter > ------------------------------------------------------------- > > Key: TEIID-3290 > URL: https://issues.jboss.org/browse/TEIID-3290 > Project: Teiid > Issue Type: Enhancement > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > > Currently only query parameters are supported as the input parameters to the Teiid procedure in POST based call. > The POST BODY also needs to be supported to handle larger payloads in this situation as query parameters has size limitations. Currently string based query parameters are supported, but since they passed as is as strings on larger payloads the they will be subject 4000 string length restriction. > It should be possible to read metadata of the procedure and convert the string objects to respective objects before the query gets executed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3295) Change subqueryUnnestDefault to true

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3295: ------------------------------------- Summary: Change subqueryUnnestDefault to true Key: TEIID-3295 URL: https://issues.jboss.org/browse/TEIID-3295 Project: Teiid Issue Type: Enhancement Components: Query Engine Affects Versions: 8.10 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.10 Since TEIID-2149 the scope of the property has been limited in scope and should be flipped to true to allow for more efficient planning. In the worst case users can use the NO_UNNEST hint to prevent the optimization. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 January 2015