October 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3662) IN predicate against a materialized/temp table index without an order by returns wrong results

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3662?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-3662. --------------------------------- > IN predicate against a materialized/temp table index without an order by returns wrong results > ---------------------------------------------------------------------------------------------- > > Key: TEIID-3662 > URL: https://issues.jboss.org/browse/TEIID-3662 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Tom Arnold > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.7.1.6_2, 8.12, 8.11.3, 8.7.5 > > > Seeing strange behavior when doing a simple select from {{SPATIAL_REF_SYS}}. > This works as expected: > {code} > select srid, proj4text from spatial_ref_sys where srid in (3875,4326); > srid | proj4text > ------+---------------------------------------------------------------------------------------------------------------- > 3875 | +proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=21500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs > 4326 | +proj=longlat +datum=WGS84 +no_defs > (2 rows) > {code} > Swapping the values in the IN causes only one row to be returned. > {code} > select srid, proj4text from spatial_ref_sys where srid in (4326,3875); > srid | proj4text > ------+------------------------------------- > 4326 | +proj=longlat +datum=WGS84 +no_defs > (1 row) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3671) filter on child table not working

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3671?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3671: --------------------------------------- Juraj, you have marked this as verified but reopened. Should this issue be closed now and/or a new issue opened for what you saw above? > filter on child table not working > --------------------------------- > > Key: TEIID-3671 > URL: https://issues.jboss.org/browse/TEIID-3671 > Project: Teiid > Issue Type: Bug > Components: OData > Reporter: Prashanthi Kairuppala > Assignee: Johnathon Lee > Priority: Critical > Fix For: 8.12, 8.11.4, 8.7.5 > > Attachments: parent_childTables.PNG > > > > Please find the screenshot attached which has id as a foreign key. when i give the url - //localhost:8080/odata/testVDB/sales('13')/sales_uk?$format=json, i get the results from sales_uk table which are having id=13. > > Now i am trying to apply a filter on this url, i am supposed to get results which are having id=13 and satisfy the filter condition, but this url blindly returns me data from sales_uk table which satisfy the filter condition. URL- //localhost:8080/odata/testVDB/sales('13')/sales_uk?$format=json&$filter=DISCOUNT eq '22' > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3483) Add an option to use DatabaseMetaData for hive/impala import

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3483?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-3483. --------------------------------- > Add an option to use DatabaseMetaData for hive/impala import > ------------------------------------------------------------ > > Key: TEIID-3483 > URL: https://issues.jboss.org/browse/TEIID-3483 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.11, 8.7.5 > > > With minor modifications I've confirmed that hive .13 + can do an import using the standard databasemetadata logic. Also hive .12 with a .13 server seems to have an issue with the describe table statement such that the column types are null. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3553) Odata - if table name is ambiguous, teiid returns result from first table

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3553?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-3553. --------------------------------- > Odata - if table name is ambiguous, teiid returns result from first table > ------------------------------------------------------------------------- > > Key: TEIID-3553 > URL: https://issues.jboss.org/browse/TEIID-3553 > Project: Teiid > Issue Type: Quality Risk > Components: OData > Affects Versions: 8.7.1.6_2 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.12, 8.7.5 > > > If table name is ambiguous, teiid returns data from first matching table. I expect, that it should return error message similar to exception which is thrown via JDBC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3707?page=com.atlassian.jira.plugin... ] Steven Hawkins closed 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)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3696) Duplicates are not always removed when UNION and GROUP BY clauses are used in a subquery

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3696?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-3696. --------------------------------- > Duplicates are not always removed when UNION and GROUP BY clauses are used in a subquery > ---------------------------------------------------------------------------------------- > > Key: TEIID-3696 > URL: https://issues.jboss.org/browse/TEIID-3696 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.1 > Reporter: Salvatore R > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.12, 8.11.4, 8.7.5 > > > In some cases, duplicates are not correctly removed when a UNION clause and a GROUP BY are used in a subquery. > Given, for example, these two views: > {code:sql} > CREATE view v1 as > select 'a' as col1 > UNION > SELECT '' as col1; > CREATE view v2 as > select 'b' as col1 > UNION > SELECT '' as col1; > {code} > running the following query (both col1 and col2 are projected by the main query): > {code:sql} > select > y.col2, y.col1 > from ( > select x.col2, min(x.col1) as col1 > from ( > select 1 as col2, col1 from "views.v1" > union > select 1 as col2, col1 from "views.v2" > ) x > group by x.col2 > ) y > {code} > only 1 row is returned as expected: > ||col2||col1|| > |1| | > but if only "col2" is projected by the main query: > {code:sql} > select > y.col2 > from ( > select x.col2, min(x.col1) as col1 > from ( > select 1 as col2, col1 from "views.v1" > union > select 1 as col2, col1 from "views.v2" > ) x > group by x.col2 > ) y > {code} > three rows are returned: > ||col2|| > |1| > |1| > |1| > This behavior can be reproduced in Teiid-8.12-Beta1. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3698) non-selectable columns will cause OData failures

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3698?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-3698. --------------------------------- > non-selectable columns will cause OData failures > ------------------------------------------------ > > Key: TEIID-3698 > URL: https://issues.jboss.org/browse/TEIID-3698 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: CR1 > Fix For: 8.12, 8.7.5 > > > An odata table/view with a non-selectable column will return an error if it is returned as an odata entity without the $select option to exclude the non-selectable column. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3692) Impala/Hive string literals

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3692?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-3692. --------------------------------- > Impala/Hive string literals > --------------------------- > > Key: TEIID-3692 > URL: https://issues.jboss.org/browse/TEIID-3692 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Don Krapohl > Assignee: Steven Hawkins > Fix For: 8.12, 8.11.4, 8.7.5 > > > The Hive/Impala logic does not account for the source using c-style strings and will currently for string literals in the source sql use ansi style instead. Bind values are unaffected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3796) It is much more slow to get the table record through TEIID from postgresql DB

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3796?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3796: --------------------------------------- > But when I make this table in Postgresql DB, and query through Teiid, it is so slow and will get about 8min+ client can not get the data stream, when I try to directly connect this table in Postgresql table, it is much more faster, I do not know the reason. There's not quite enough information here yet. What is the user query you are running? What is the query plan? Is there a reason you are setting disableLocalTxn? And by direct connection do you mean making a connection via the same connection pool in the same EAP vm or from a different mechanism? You need to do the former to fully compare. > It is much more slow to get the table record through TEIID from postgresql DB > ----------------------------------------------------------------------------- > > Key: TEIID-3796 > URL: https://issues.jboss.org/browse/TEIID-3796 > Project: Teiid > Issue Type: Bug > Reporter: Xian Liu > Assignee: Steven Hawkins > > There is a table about 1000K+ record > Postgresql Version: server 9.2.7 > Postgresql DB JDBC Driver Version: postgresql-9.3-1103.jdbc4.jar > The table definition: > {code} > | Type | Modifiers > ------------+-----------------------------+------------------------------------------------------------ > | integer | not null > | integer | > | integer | not null > | timestamp without time zone | not null > | integer | not null > | text | > | text | > | bigint | > | bigint | not null > | integer | > {code} > I set driver connection parameter to disableLocalTxn=true;FetchSize=10; > 1. When I make this table available in Mysql, and select * from it in Teiid, It will quickly get the data stream after around 30s. > 2. But when I make this table in Postgresql DB, and query through Teiid, it is so slow and will get about 8min+ client can not get the data stream, > when I try to directly connect this table in Postgresql table, it is much more faster, I do not know the reason. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3796) It is much more slow to get the table record through TEIID from postgresql DB

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-3796?page=com.atlassian.jira.plugin... ] Kylin Soong edited comment on TEIID-3796 at 10/30/15 5:29 AM: -------------------------------------------------------------- Query with Teiid slow may caused by GC, have you tried a larger heap(-Xms4096m -Xmx4096m)? was (Author: kylin): Query with Teiid slow may caused by GC, have you ever tried a larger heap(-Xms4096m -Xmx4096m)? > It is much more slow to get the table record through TEIID from postgresql DB > ----------------------------------------------------------------------------- > > Key: TEIID-3796 > URL: https://issues.jboss.org/browse/TEIID-3796 > Project: Teiid > Issue Type: Bug > Reporter: Xian Liu > Assignee: Steven Hawkins > > There is a table about 1000K+ record > Postgresql Version: server 9.2.7 > Postgresql DB JDBC Driver Version: postgresql-9.3-1103.jdbc4.jar > The table definition: > {code} > | Type | Modifiers > ------------+-----------------------------+------------------------------------------------------------ > | integer | not null > | integer | > | integer | not null > | timestamp without time zone | not null > | integer | not null > | text | > | text | > | bigint | > | bigint | not null > | integer | > {code} > I set driver connection parameter to disableLocalTxn=true;FetchSize=10; > 1. When I make this table available in Mysql, and select * from it in Teiid, It will quickly get the data stream after around 30s. > 2. But when I make this table in Postgresql DB, and query through Teiid, it is so slow and will get about 8min+ client can not get the data stream, > when I try to directly connect this table in Postgresql table, it is much more faster, I do not know the reason. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues October 2015