January 2015 - teiid-issues - Jboss List Archives

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-3296: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1185068 > 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 > Components: Query Engine > Affects Versions: 8.2 > Reporter: Salvatore R > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.10 > > > 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)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3272) JDBC Translator | Segregation of batch execution and commit mode

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3272?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3272. ----------------------------------- Resolution: Rejected Control of batch commit as written in this enhancement is not something that we can pursue. A related and potentially valid approach would be to allow the use of source connections in a more directly controlled local transaction mode. This would look something like not automatically starting a global transaction on a Teiid client local transaction and tracking connections via transaction on the server side. With the issue of course that when using multiple sources the commits will not be coordinated. > JDBC Translator | Segregation of batch execution and commit mode > ----------------------------------------------------------------- > > Key: TEIID-3272 > URL: https://issues.jboss.org/browse/TEIID-3272 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector > Reporter: Shiveeta Mattoo > Assignee: Steven Hawkins > Labels: Batch-Commit, JDBC-Transator > Attachments: batch1.png > > > In JDBC Translator, the batch execution and commit are coupled together. Hence, we after every batch execution, a commit is executed. > This enhancement is for providing an ability to support the commit after a configurable 'x' no. of batches has completed, instead of an automatic commit after every batch. > The no of batches after which a commit is desired should be a configurable option. > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

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

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3298?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3298: ------------------------------------- JSON sounds good, may be we can just post a parsing routine along with it, so that we establish the parsing routine > 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)

9 years, 11 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3296: ---------------------------------- Priority: Blocker (was: Major) > 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 > Components: Query Engine > Affects Versions: 8.2 > Reporter: Salvatore R > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.10 > > > 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)

9 years, 11 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3298?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3298: --------------------------------------- There is quite of bit of information that could be useful. Adding an out parameter for each is possible. Other approaches would be to have a resultset with name value pair columns (which could be cumbersome to use) or a json value (since we lack a map construct). > 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)

9 years, 11 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3290?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-3290: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1185024 > 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)

9 years, 11 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-3296 at 1/22/15 11:38 AM: ----------------------------------------------------------------- Added predicates containing non-column reference expressions to be preserved. This needs to be queued for 8.7.x was (Author: shawkins): Added predicates containing non-column reference expressions to be preserved. > 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 > Components: Query Engine > Affects Versions: 8.2 > Reporter: Salvatore R > Assignee: Steven Hawkins > Fix For: 8.10 > > > 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)

9 years, 11 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3296: ---------------------------------- Fix Version/s: 8.10 Affects Version/s: 8.2 Component/s: Query Engine Forum Reference: https://developer.jboss.org/message/916717 The fix from TEIID-2190 was incomplete. This should have been addressed at that time. > 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 > Components: Query Engine > Affects Versions: 8.2 > Reporter: Salvatore R > Assignee: Steven Hawkins > Fix For: 8.10 > > > 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)

9 years, 11 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3296. ----------------------------------- Resolution: Done Added predicates containing non-column reference expressions to be preserved. > 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 > Components: Query Engine > Affects Versions: 8.2 > Reporter: Salvatore R > Assignee: Steven Hawkins > Fix For: 8.10 > > > 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)

9 years, 11 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 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)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2015