[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)
9 years, 11 months
[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)
9 years, 11 months
[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)
9 years, 11 months
[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)
9 years, 11 months
[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)
9 years, 11 months
[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)
9 years, 11 months
[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)
9 years, 11 months
[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)
9 years, 11 months
[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)
9 years, 11 months
[JBoss JIRA] (TEIID-2384) Managing Spatial Data Types
by Tom Arnold (JIRA)
[ https://issues.jboss.org/browse/TEIID-2384?page=com.atlassian.jira.plugin... ]
Tom Arnold edited comment on TEIID-2384 at 1/22/15 12:55 AM:
-------------------------------------------------------------
{quote}
jts does not care if the srid matches when performing the various system functions. We may need to restrict to only matching srids to stay consistent with expected source behavior.
{quote}
Oracle and PostGIS will reproject (ST_Transform) in the case where the SRIDs do not match. For other sources I think we should error, with an eye towards implementing ST_Transform as a system function:
# Add ST_Transform as a CAN_PUSHDOWN with an implementation that just says "reprojection not currently supported".
# Add ST_Transform as supported function for Oracle & PostGIS.
# In mismatched-SRID situations, wrap geometry literal in ST_Transform to do conversion to target SRID. (Dependency on storing SRID in column metadata for this to work.)
# Change ST_Transform system function to actually do reprojection. I will spend some time in GeoTools trying to get a better understanding of how this works.
was (Author: tom9729):
{quote}
jts does not care if the srid matches when performing the various system functions. We may need to restrict to only matching srids to stay consistent with expected source behavior.
{quote}
Oracle and PostGIS will reproject (ST_Transform) in the case where the SRIDs do not match. For other sources I think we should error, with an eye towards implementing ST_Transform as a system function:
# Add ST_Transform as a CAN_PUSHDOWN with an implementation that just says "reprojection not currently supported". Add as supported function for Oracle & PostGIS.
# In mismatched-SRID situations, wrap geometry literal in ST_Transform to do conversion to target SRID. (Dependency on storing SRID in column metadata for this to work.)
# Change ST_Transform system function to actually do reprojection. I will spend some time in GeoTools trying to get a better understanding of how this works.
> Managing Spatial Data Types
> ---------------------------
>
> Key: TEIID-2384
> URL: https://issues.jboss.org/browse/TEIID-2384
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Labels: spatial, types
> Fix For: 8.10
>
>
> It would be useful to be able to consume data from spatial database exposing the VDB as a spatial database to other application (imagine geoserver).
> TEIID could be strategic for merging georeferenced data and make it available to those systems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months