June 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3707) Wrong Data returned when a procedure is executed in the SELECT clause

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3707?page=com.atlassian.jira.plugin... ] Johnathon Lee closed TEIID-3707. -------------------------------- Resolution: Done > Wrong Data returned when a procedure is executed in the SELECT clause > --------------------------------------------------------------------- > > Key: TEIID-3707 > URL: https://issues.jboss.org/browse/TEIID-3707 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.6 > Reporter: dalex dalex > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.7.7.6_2, 8.7.5, 8.11.5, 8.12 > > Attachments: highcpu-threads.png, out.1, out.2, out.3, sample_coords.sql, wrong_data.jpg > > > I've found the following problem when executing a stored procedure in the SELECT clause. It calculates wrong data in a seemingly random fashion. > This is a stored procedure which was created to determine whether a given coordinate lies within a specific rectangle. If this procedure is tested in a simple manner (SELECT .. FROM (EXEC ..)) the results are correctly retuned (0 = outside the rectangle and 1 otherwise). > {code:sql} > CREATE virtual procedure point_inside_store ( > pos_x float > ,pos_y float > ) RETURNS ( > "insideFence" integer > ) AS > BEGIN > DECLARE integer insideFence = 0 ; > DECLARE float lowerLimit = 0.0 ; > DECLARE float upperLimit = 17.0 ; > DECLARE float leftLimit = 0.0 ; > DECLARE float rightLimit = 53.0 ; > IF ( > pos_x >= leftLimit > AND pos_x <= rightLimit > AND pos_y >= lowerLimit > AND pos_y <= upperLimit > ) > BEGIN > insideFence = 1 ; > END > SELECT > insideFence ; > END > {code} > If now the same procedure is included in a SELECT clause of a query: > {code:sql} > SELECT > "citmp.KoordX" > ,"citmp.KoordY" > ,( > SELECT > "store.insideFence" > FROM > ( > EXEC procs.point_inside_store ( > CAST ( > "citmp.KoordX" AS float > ) > ,CAST ( > "citmp.KoordY" AS float > ) > ) > ) as "store" > ) as "insideStore" > ,( > SELECT > "firstsection.insideFence" > FROM > ( > EXEC procs.point_inside_store ( > CAST ( > "citmp.KoordX" AS float > ) > ,CAST ( > "citmp.KoordY" AS float > ) > ) > ) as "firstsection" > ) as "insideFirstsection" > FROM > "test.sample_coords" as "citmp" > ORDER BY > insideStore ASC > ,insideFirstsection DESC;; > {code} > it calculates different results. The same coordinates that yielded 0 before now yield 1. > !wrong_data.jpg|thumbnail! > Note that the main query has 2 columns executing the exact same procedure but there are result sets, that have different values in the last two columns. This should not be possible. > In attachment you will find sample_coords table with a sample of coordinates. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3707) Wrong Data returned when a procedure is executed in the SELECT clause

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3707?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3707: --------------------------------- Fix Version/s: 8.7.7.6_2 > Wrong Data returned when a procedure is executed in the SELECT clause > --------------------------------------------------------------------- > > Key: TEIID-3707 > URL: https://issues.jboss.org/browse/TEIID-3707 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.6 > Reporter: dalex dalex > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.12, 8.11.5, 8.7.5, 8.7.7.6_2 > > Attachments: highcpu-threads.png, out.1, out.2, out.3, sample_coords.sql, wrong_data.jpg > > > I've found the following problem when executing a stored procedure in the SELECT clause. It calculates wrong data in a seemingly random fashion. > This is a stored procedure which was created to determine whether a given coordinate lies within a specific rectangle. If this procedure is tested in a simple manner (SELECT .. FROM (EXEC ..)) the results are correctly retuned (0 = outside the rectangle and 1 otherwise). > {code:sql} > CREATE virtual procedure point_inside_store ( > pos_x float > ,pos_y float > ) RETURNS ( > "insideFence" integer > ) AS > BEGIN > DECLARE integer insideFence = 0 ; > DECLARE float lowerLimit = 0.0 ; > DECLARE float upperLimit = 17.0 ; > DECLARE float leftLimit = 0.0 ; > DECLARE float rightLimit = 53.0 ; > IF ( > pos_x >= leftLimit > AND pos_x <= rightLimit > AND pos_y >= lowerLimit > AND pos_y <= upperLimit > ) > BEGIN > insideFence = 1 ; > END > SELECT > insideFence ; > END > {code} > If now the same procedure is included in a SELECT clause of a query: > {code:sql} > SELECT > "citmp.KoordX" > ,"citmp.KoordY" > ,( > SELECT > "store.insideFence" > FROM > ( > EXEC procs.point_inside_store ( > CAST ( > "citmp.KoordX" AS float > ) > ,CAST ( > "citmp.KoordY" AS float > ) > ) > ) as "store" > ) as "insideStore" > ,( > SELECT > "firstsection.insideFence" > FROM > ( > EXEC procs.point_inside_store ( > CAST ( > "citmp.KoordX" AS float > ) > ,CAST ( > "citmp.KoordY" AS float > ) > ) > ) as "firstsection" > ) as "insideFirstsection" > FROM > "test.sample_coords" as "citmp" > ORDER BY > insideStore ASC > ,insideFirstsection DESC;; > {code} > it calculates different results. The same coordinates that yielded 0 before now yield 1. > !wrong_data.jpg|thumbnail! > Note that the main query has 2 columns executing the exact same procedure but there are result sets, that have different values in the last two columns. This should not be possible. > In attachment you will find sample_coords table with a sample of coordinates. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3707) Wrong Data returned when a procedure is executed in the SELECT clause

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3707?page=com.atlassian.jira.plugin... ] Johnathon Lee reopened TEIID-3707: ---------------------------------- > Wrong Data returned when a procedure is executed in the SELECT clause > --------------------------------------------------------------------- > > Key: TEIID-3707 > URL: https://issues.jboss.org/browse/TEIID-3707 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.6 > Reporter: dalex dalex > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.12, 8.11.5, 8.7.5 > > Attachments: highcpu-threads.png, out.1, out.2, out.3, sample_coords.sql, wrong_data.jpg > > > I've found the following problem when executing a stored procedure in the SELECT clause. It calculates wrong data in a seemingly random fashion. > This is a stored procedure which was created to determine whether a given coordinate lies within a specific rectangle. If this procedure is tested in a simple manner (SELECT .. FROM (EXEC ..)) the results are correctly retuned (0 = outside the rectangle and 1 otherwise). > {code:sql} > CREATE virtual procedure point_inside_store ( > pos_x float > ,pos_y float > ) RETURNS ( > "insideFence" integer > ) AS > BEGIN > DECLARE integer insideFence = 0 ; > DECLARE float lowerLimit = 0.0 ; > DECLARE float upperLimit = 17.0 ; > DECLARE float leftLimit = 0.0 ; > DECLARE float rightLimit = 53.0 ; > IF ( > pos_x >= leftLimit > AND pos_x <= rightLimit > AND pos_y >= lowerLimit > AND pos_y <= upperLimit > ) > BEGIN > insideFence = 1 ; > END > SELECT > insideFence ; > END > {code} > If now the same procedure is included in a SELECT clause of a query: > {code:sql} > SELECT > "citmp.KoordX" > ,"citmp.KoordY" > ,( > SELECT > "store.insideFence" > FROM > ( > EXEC procs.point_inside_store ( > CAST ( > "citmp.KoordX" AS float > ) > ,CAST ( > "citmp.KoordY" AS float > ) > ) > ) as "store" > ) as "insideStore" > ,( > SELECT > "firstsection.insideFence" > FROM > ( > EXEC procs.point_inside_store ( > CAST ( > "citmp.KoordX" AS float > ) > ,CAST ( > "citmp.KoordY" AS float > ) > ) > ) as "firstsection" > ) as "insideFirstsection" > FROM > "test.sample_coords" as "citmp" > ORDER BY > insideStore ASC > ,insideFirstsection DESC;; > {code} > it calculates different results. The same coordinates that yielded 0 before now yield 1. > !wrong_data.jpg|thumbnail! > Note that the main query has 2 columns executing the exact same procedure but there are result sets, that have different values in the last two columns. This should not be possible. > In attachment you will find sample_coords table with a sample of coordinates. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4271) Consume Teiid OData from Salesforce

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4271: ------------------------------------- Summary: Consume Teiid OData from Salesforce Key: TEIID-4271 URL: https://issues.jboss.org/browse/TEIID-4271 Project: Teiid Issue Type: Feature Request Components: OData Reporter: Steven Hawkins Fix For: 9.x At least when consuming OData 2, Salesforce does not support Collection(Int16|Int32|String). Since we expose our system metadata, including pg metadata, in the OData metadata, this means that Salesforce won't consume. If the pg metadata is disabled and there are not primitive array columns in the rest of the metadata, then Salesforce can consume. Since this is working around a Salesforce issue, we shouldn't introduce too intrusive of a mechanism for this. And in general we may need to use extension metadata to allow users to exclude objects in a more granular way from being exposed in OData metadata. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4268) Add OAuth JWT documentation

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4268?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-4268: -------------------------------- Fix Version/s: 9.1 > Add OAuth JWT documentation > --------------------------- > > Key: TEIID-4268 > URL: https://issues.jboss.org/browse/TEIID-4268 > Project: Teiid > Issue Type: Task > Components: Documentation > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 9.1, 8.12.5 > > > Move the docs from JIRA here https://issues.jboss.org/browse/TEIID-3618 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4268) Add OAuth JWT documentation

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4268?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-4268: -------------------------------- Fix Version/s: 8.12.5 > Add OAuth JWT documentation > --------------------------- > > Key: TEIID-4268 > URL: https://issues.jboss.org/browse/TEIID-4268 > Project: Teiid > Issue Type: Task > Components: Documentation > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > Move the docs from JIRA here https://issues.jboss.org/browse/TEIID-3618 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4266) Convert the Teiid examples to gitbook

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4266?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4266: ------------------------------------- We need to move [2] rest all look like stubbed page links to other places. Ideally I would want all the documentation about examples (including designer) single place, but right now Teiid specific is fine Anything you move goes to [a] [a] https://github.com/teiid/teiid-quickstarts > Convert the Teiid examples to gitbook > ------------------------------------- > > Key: TEIID-4266 > URL: https://issues.jboss.org/browse/TEIID-4266 > Project: Teiid > Issue Type: Task > Components: Documentation > Reporter: Steven Hawkins > Assignee: Kylin Soong > Fix For: 9.1 > > > https://docs.jboss.org/author/display/teiidexamples/Home should be added to our gitbook documentation set to complete the move out of Confluence. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4090) Issue with entitysets/properties ending in auth or token

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4090?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4090: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1346025|https://bugzilla.redhat.com/show_bug.cgi?id=1346025] from NEW to MODIFIED > Issue with entitysets/properties ending in auth or token > -------------------------------------------------------- > > Key: TEIID-4090 > URL: https://issues.jboss.org/browse/TEIID-4090 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Blocker > Labels: Final > Fix For: 9.0, 8.12.5 > > > To handle oauth, we are check for uri.endsWith("auth") || uri.endsWith("token") - however valid uris can end with those characters as well. An ioexception will be thrown instead of seeing the expected results - we also need to not simply throw an ioexception in ODataServlet as there is no server log of the exception and the client sees a 500 error. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4269) numeric calculated fields not displayed with odata4

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4269?page=com.atlassian.jira.plugin... ] Ramesh Reddy reassigned TEIID-4269: ----------------------------------- Assignee: Ramesh Reddy (was: Steven Hawkins) > numeric calculated fields not displayed with odata4 > --------------------------------------------------- > > Key: TEIID-4269 > URL: https://issues.jboss.org/browse/TEIID-4269 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.13.3 > Reporter: Mirco Marchitiello > Assignee: Ramesh Reddy > Priority: Minor > > I've created a virtual table with a new field defined in this way: > select ROUND((BA.PREIS / BA.PEINH), 3) AS UnitPrice from xxxxxx > for the source field are bigdecimal I define UnitPrice as > BigDecimal (13,3) > If I run the qery from JDBC > select * from PurchaseRequisitionEntity where PurchaseRequisitionKey = '300-8000001452-00010' ; > PREIS = 539,568 > PEINH = 106 > UnitPrice = 5,090.264 > And the result is correct. If I run from odata2 > /odata/CASALE.1/Entities.PurchaseRequisitionEntity('300-8000001452-00010')?$format=json > "UnitPrice" : "5090.2640000000000000" > As you can see the field is rounded to the 3rd digit but 13 more digits are returned with 0 value. > Anyway odata2 succeeds in returning the result without errors. > With odata4 I get an error: > /odata4/CASALE.1/Entities/PurchaseRequisitionEntity('300-8000001452-00010')?$format=json > {"error":{"code":null,"message":"The value '5090.2640000000000000' is not valid for property 'UnitPrice'."}} > I think that's because the length of the field is greater then the matedata definition. > At the moment the only solution I can imagine is to convert the number to a string in the proper format and the parse it into a number -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3628) Server socket setting issues

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3628?page=com.atlassian.jira.plugin... ] Johnathon Lee closed TEIID-3628. -------------------------------- Resolution: Done > Server socket setting issues > ---------------------------- > > Key: TEIID-3628 > URL: https://issues.jboss.org/browse/TEIID-3628 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.7.6_2, 8.7.5, 8.11.3, 8.12 > > > The bootstrap settings need to be for the child rather than the parent. Also we should enable tcpNoDelay so that small messages are immediately sent. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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 June 2016