[JBoss JIRA] (TEIID-5016) Exploit left outer join associativity prior to join planning
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-5016:
-------------------------------------
Summary: Exploit left outer join associativity prior to join planning
Key: TEIID-5016
URL: https://issues.jboss.org/browse/TEIID-5016
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 10.0
Building upon TEIID-3652 there are circumstances where nested left outer joins can have be converted to an inner join prior to join planning. They can be converted back to a left outer join by TEIID-3652 if needed for pushdown after join planning.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (TEIID-5014) Unable to use parameterized query with node pg module and Teiid/JBoss VDB
by Brian M (JIRA)
[ https://issues.jboss.org/browse/TEIID-5014?page=com.atlassian.jira.plugin... ]
Brian M commented on TEIID-5014:
--------------------------------
Ah! Your theory is the same as the theory we came up with when looking at the node pg module source code. We will try with a latest and see what happens. Thank you, Ramesh!
> Unable to use parameterized query with node pg module and Teiid/JBoss VDB
> -------------------------------------------------------------------------
>
> Key: TEIID-5014
> URL: https://issues.jboss.org/browse/TEIID-5014
> Project: Teiid
> Issue Type: Feature Request
> Affects Versions: 8.7.11.6_2
> Environment: Teiid runtime 8.7.11
> JBoss Data Virtualization 6.10
> NodeJS 6.9.4
> node pg 6.4.1
> Mac OSX 10.11.6
> Reporter: Brian M
> Assignee: Steven Hawkins
>
> When using node pg 6.4.1 in a node application to connect to a JBoss VDB with Teiid, we are unable to successfully return data with a parameterized query.
> Example from node js application (failure):
> client.query("SELECT * FROM records WHERE recordType = $1", ['TYPE1'], function(err, result) { done(); })
> The above code will actually retrieve rows of data, but the connection will be terminated unexpectedly from the JBoss side, thus resulting in a failure. We can confirm though that the parameter is properly inserted into the variable, and rows of data can be retrieved without issue.
> Also, we have confirmed that when sending a static query, we are able to successfully return data without JBoss terminating the connection. We found this approach from the Teiid blog: http://teiid.blogspot.com/2013/02/access-teiid-from-nodejs.html
> Example from node js application (success):
> client.query("SELECT * FROM records WHERE recordType = 'TYPE1'", function(err, result) { done(); })
> Is there something different about a parameterized query vs. a static query that may cause this issue?
> Are you aware of other individuals who have successfully used parameterized queries with the node pg module and Teiid/JBoss VDB?
> Is it possible that how the ODBC settings for Teiid are configured may have an impact on parameterized queries vs. static queries?
> Link: https://teiid.gitbooks.io/documents/content/client-dev/ODBC_Support.html
> Thank you so much for all your help!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (TEIID-4981) Support Amazon S3 Transaltor
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4981?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4981:
-------------------------------------
The REST support is already there is reach Amazon S3, however, there is no provided mechanism to send the "Authorization" header. To support "Authorization", there are couple different options
- Minimally we can supply a UDF to generate the headers required then user can continue to use the "ws" translator
- Provide a specific "S3" translator with a metadata calls similar to that of file translator, where calling interface is "getTextFile', "getFile", deleteFile, saveFile etc, but use the "ws" as the resource adapter to provide a simplified interface. Where these methods support taking the access keys as parameters and generate the required headers (there are more than single header)
I am leaning towards the 2nd option, any thoughts?
> Support Amazon S3 Transaltor
> ----------------------------
>
> Key: TEIID-4981
> URL: https://issues.jboss.org/browse/TEIID-4981
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Ramesh Reddy
> Fix For: Open To Community
>
>
> Support Amazon S3 access from Teiid. Typically this is viewed as file-based access? however handling the security is key here.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (TEIID-3843) SAP HANA wrong results from MOD with float argument
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3843?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3843:
------------------------------------
tejones: They said SP10
> SAP HANA wrong results from MOD with float argument
> ---------------------------------------------------
>
> Key: TEIID-3843
> URL: https://issues.jboss.org/browse/TEIID-3843
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.2.6_2
> Reporter: Jan Stastny
> Assignee: Ted Jones
>
> SAP HANA doesn't handle correctly MOD function with float arguments. The problem occurs when the float value is less than zero.
> According to SAP HANA documentation, its MOD implementation follows the symmetric handling of MOD on less than zero values. In such case, the resulting value should be computed as:
> a is negative whole number
> n is positive whole number
> mod(a,n)
> # get -1*a
> # compute mod(-1*a,n)
> # multiply the result by -1
> # result is -1*mod(-1*a,n)
> SAP HANA follows this rule for other numeric types than float. For example for Long value -24 MOD(-24,11)=-2 , which is correct according to the MOD definition.
> But when you call MOD(-24.0,11) you get 2.0
> In current state, the only thing Teiid could do is to prevent pushing MOD with float arguments. It helps to cast explicitly the column to double.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (TEIID-3843) SAP HANA wrong results from MOD with float argument
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3843?page=com.atlassian.jira.plugin... ]
Van Halbert resolved TEIID-3843.
--------------------------------
Resolution: Done
> SAP HANA wrong results from MOD with float argument
> ---------------------------------------------------
>
> Key: TEIID-3843
> URL: https://issues.jboss.org/browse/TEIID-3843
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.2.6_2
> Reporter: Jan Stastny
> Assignee: Ted Jones
>
> SAP HANA doesn't handle correctly MOD function with float arguments. The problem occurs when the float value is less than zero.
> According to SAP HANA documentation, its MOD implementation follows the symmetric handling of MOD on less than zero values. In such case, the resulting value should be computed as:
> a is negative whole number
> n is positive whole number
> mod(a,n)
> # get -1*a
> # compute mod(-1*a,n)
> # multiply the result by -1
> # result is -1*mod(-1*a,n)
> SAP HANA follows this rule for other numeric types than float. For example for Long value -24 MOD(-24,11)=-2 , which is correct according to the MOD definition.
> But when you call MOD(-24.0,11) you get 2.0
> In current state, the only thing Teiid could do is to prevent pushing MOD with float arguments. It helps to cast explicitly the column to double.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (TEIID-4918) Enhance infinispan support for muti-threaded puts or using putAll
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4918?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-4918 at 8/6/17 8:01 PM:
-------------------------------------------------------------
I thought JDG cache store is a blob storage not sure if one of the load strategies is load from SQL query to work a Teiid view? Even then update is not straight forward, as it is cache "put".
> There is also perhaps some way of by-passing puts/putall and writing directly to a store and then starting a cache in the materialization case.
Remote functions do give this ability to by pass the cache API, but it was not clear to me without spending more time and more over the Protostream stuff was another hurdle. Basically, the interaction will be
Teiid --> send a blob of data (say java serialization) --> wire to infinispan --> deseriliaze (java serilization) --> check for duplicate keys --> store in grid in protostream marshalled form
I saw too many things could be going wrong here, it may be better we work with Infinispan folks to drive to a correct solution.
was (Author: rareddy):
I thought JDG cache store is a blob storage not sure if one of the load strategies is load from SQL query to work a Teiid view? Even then update is straight forward, as it is cache "put".
> There is also perhaps some way of by-passing puts/putall and writing directly to a store and then starting a cache in the materialization case.
Remote functions do give this ability to by pass the cache API, but it was not clear to me without spending more time and more over the Protostream stuff was another hurdle. Basically, the interaction will be
Teiid --> send a blob of data (say java serialization) --> wire to infinispan --> deseriliaze (java serilization) --> check for duplicate keys --> store in grid in protostream marshalled form
I saw too many things could be going wrong here, it may be better we work with Infinispan folks to drive to a correct solution.
> Enhance infinispan support for muti-threaded puts or using putAll
> -----------------------------------------------------------------
>
> Key: TEIID-4918
> URL: https://issues.jboss.org/browse/TEIID-4918
> Project: Teiid
> Issue Type: Enhancement
> Components: Infinispan
> Affects Versions: 9.3, 8.12.x-6.4
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Fix For: 10.0
>
>
> For performance reasons, it was requested that the infinispan connector/translator be enhanced to be multi-threaded when doing batch inserts or try using the putAll option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (TEIID-4918) Enhance infinispan support for muti-threaded puts or using putAll
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4918?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-4918 at 8/6/17 8:01 PM:
-------------------------------------------------------------
I thought JDG cache store is a blob storage not sure if one of the load strategies is load from SQL query to work a Teiid view? Even then update is not straight forward, as it is not cache "put".
> There is also perhaps some way of by-passing puts/putall and writing directly to a store and then starting a cache in the materialization case.
Remote functions do give this ability to by pass the cache API, but it was not clear to me without spending more time and more over the Protostream stuff was another hurdle. Basically, the interaction will be
Teiid --> send a blob of data (say java serialization) --> wire to infinispan --> deseriliaze (java serilization) --> check for duplicate keys --> store in grid in protostream marshalled form
I saw too many things could be going wrong here, it may be better we work with Infinispan folks to drive to a correct solution.
was (Author: rareddy):
I thought JDG cache store is a blob storage not sure if one of the load strategies is load from SQL query to work a Teiid view? Even then update is not straight forward, as it is cache "put".
> There is also perhaps some way of by-passing puts/putall and writing directly to a store and then starting a cache in the materialization case.
Remote functions do give this ability to by pass the cache API, but it was not clear to me without spending more time and more over the Protostream stuff was another hurdle. Basically, the interaction will be
Teiid --> send a blob of data (say java serialization) --> wire to infinispan --> deseriliaze (java serilization) --> check for duplicate keys --> store in grid in protostream marshalled form
I saw too many things could be going wrong here, it may be better we work with Infinispan folks to drive to a correct solution.
> Enhance infinispan support for muti-threaded puts or using putAll
> -----------------------------------------------------------------
>
> Key: TEIID-4918
> URL: https://issues.jboss.org/browse/TEIID-4918
> Project: Teiid
> Issue Type: Enhancement
> Components: Infinispan
> Affects Versions: 9.3, 8.12.x-6.4
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Fix For: 10.0
>
>
> For performance reasons, it was requested that the infinispan connector/translator be enhanced to be multi-threaded when doing batch inserts or try using the putAll option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (TEIID-4918) Enhance infinispan support for muti-threaded puts or using putAll
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4918?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4918:
-------------------------------------
I thought JDG cache store is a blob storage not sure if one of the load strategies is load from SQL query to work a Teiid view? Even then update is straight forward, as it is cache "put".
> There is also perhaps some way of by-passing puts/putall and writing directly to a store and then starting a cache in the materialization case.
Remote functions do give this ability to by pass the cache API, but it was not clear to me without spending more time and more over the Protostream stuff was another hurdle. Basically, the interaction will be
Teiid --> send a blob of data (say java serialization) --> wire to infinispan --> deseriliaze (java serilization) --> check for duplicate keys --> store in grid in protostream marshalled form
I saw too many things could be going wrong here, it may be better we work with Infinispan folks to drive to a correct solution.
> Enhance infinispan support for muti-threaded puts or using putAll
> -----------------------------------------------------------------
>
> Key: TEIID-4918
> URL: https://issues.jboss.org/browse/TEIID-4918
> Project: Teiid
> Issue Type: Enhancement
> Components: Infinispan
> Affects Versions: 9.3, 8.12.x-6.4
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Fix For: 10.0
>
>
> For performance reasons, it was requested that the infinispan connector/translator be enhanced to be multi-threaded when doing batch inserts or try using the putAll option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months