August 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5317) Add support for ODBC 3.0 functions

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-5317?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-5317: --------------------------------- Fix Version/s: 8.12.15.6_4 > Add support for ODBC 3.0 functions > ---------------------------------- > > Key: TEIID-5317 > URL: https://issues.jboss.org/browse/TEIID-5317 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 8.12.12.6_4 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 10.3, 8.12.15.6_4 > > > Looking to add support for ODBC 3 functions like "CURRENT_TIMESTAMP" and "CURRENT_DATE()" as indicated in linke [1]. This would be in support of applications that auto-generate backend SQL such as Tableau or Spotfire. > [1] https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/time-date-... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5440) Couchbase translator - LET usage prevents index scan

by Jan Stastny (JIRA)

[ https://issues.jboss.org/browse/TEIID-5440?page=com.atlassian.jira.plugin... ] Jan Stastny commented on TEIID-5440: ------------------------------------ [~shawkins] The original issue also affects results being returned. Consider these 3 queries (n1ql): # Two LET variables in WHERE criteria #* {code:sql} SELECT `$cb_c1_StringKey` c_0 FROM `dvqe_small` `$cb_t1` LET `$cb_c1_StringKey` = `$cb_t1`.`stringkey`, `$cb_c2_IntNum` = `$cb_t1`.`intnum`, `$type`=`$cb_t1`.`type` WHERE `$cb_c2_IntNum` = 22 AND `$type` = 'smalla' LIMIT 2 {code} #* returns single row with value 46. #* Does not use pre-defined index on `type` # One LET variable and one column reference in WHERE criteria #* {code:sql} SELECT `$cb_c1_StringKey` c_0 FROM `dvqe_small` `$cb_t1` LET `$cb_c1_StringKey` = `$cb_t1`.`stringkey`, `$cb_c2_IntNum` = `$cb_t1`.`intnum` WHERE `$cb_c2_IntNum` = 22 AND `$cb_t1`.`type` = 'smalla' LIMIT 2 {code} #* returns empty result. #* Uses pre-defined index on `type` # Two column references in WHERE criteria #* {code:sql} SELECT `$cb_c1_StringKey` c_0 FROM `dvqe_small` `$cb_t1` LET `$cb_c1_StringKey` = `$cb_t1`.`stringkey` WHERE `$cb_t1`.`intnum` = 22 AND `$cb_t1`.`type` = 'smalla' LIMIT 2 {code} #* returns single row with value 46. #* Uses pre-defined index on `type` I believe using the LET clause has broader consequences than only performance hit and the issue seems more serious. > Couchbase translator - LET usage prevents index scan > ---------------------------------------------------- > > Key: TEIID-5440 > URL: https://issues.jboss.org/browse/TEIID-5440 > Project: Teiid > Issue Type: Quality Risk > Components: Misc. Connectors > Affects Versions: 8.12.14.6_4 > Reporter: Jan Stastny > Assignee: Steven Hawkins > Priority: Critical > Fix For: 11.1 > > > Couchbase translator excesively uses LET clause(1) just for purpose of naming columns. > That's not correct usage of LET clause and affects query execution in couchbase. > Simple query > {code:sql} > SELECT IntKey FROM SmallA; > {code} > is being pushed as > {code:sql} > SELECT `$cb_c1_IntKey` c1 FROM `dvqe` `$cb_t1` LET `$cb_c1_IntKey` = `$cb_t1`.`intkey` WHERE `$cb_t1`.`type` = 'smalla' > {code} > Which is fine and index on `type` column is scanned on couchbase side. > But when I issue query > {code:sql} > SELECT * FROM SmallA; > {code} > it is pushed as > {code:sql} > SELECT > `$cb_c1_documentID` c1, > `$cb_c2_FloatNum` c2, > `$cb_c3_IntKey` c3, > `$cb_c4_BigIntegerValue` c4, > `$cb_c5_StringKey` c5, > `$cb_c6_CharValue` c6, > `$cb_c7_LongNum` c7, > `$cb_c8_type` c8, > `$cb_c9_DoubleNum` c9, > `$cb_c10_ObjectValue` c10, > `$cb_c11_ShortValue` c11, > `$cb_c12_BigDecimalValue` c12, > `$cb_c13_DateValue` c13, > `$cb_c14_BooleanValue` c14, > `$cb_c15_TimestampValue` c15, > `$cb_c16_ByteNum` c16, > `$cb_c17_StringNum` c17, > `$cb_c18_TimeValue` c18, > `$cb_c19_IntNum` c19 > FROM `dvqe` `$cb_t1` > LET `$cb_c1_documentID` = META(`$cb_t1`).id, > `$cb_c2_FloatNum` = `$cb_t1`.`floatnum`, > `$cb_c3_IntKey` = `$cb_t1`.`intkey`, > `$cb_c4_BigIntegerValue` = `$cb_t1`.`bigintegervalue`, > `$cb_c5_StringKey` = `$cb_t1`.`stringkey`, > `$cb_c6_CharValue` = `$cb_t1`.`charvalue`, > `$cb_c7_LongNum` = `$cb_t1`.`longnum`, > `$cb_c8_type` = `$cb_t1`.`type`, > `$cb_c9_DoubleNum` = `$cb_t1`.`doublenum`, > `$cb_c10_ObjectValue` = `$cb_t1`.`objectvalue`, > `$cb_c11_ShortValue` = `$cb_t1`.`shortvalue`, > `$cb_c12_BigDecimalValue` = `$cb_t1`.`bigdecimalvalue`, > `$cb_c13_DateValue` = `$cb_t1`.`datevalue`, > `$cb_c14_BooleanValue` = `$cb_t1`.`booleanvalue`, > `$cb_c15_TimestampValue` = `$cb_t1`.`timestampvalue`, > `$cb_c16_ByteNum` = `$cb_t1`.`bytenum`, > `$cb_c17_StringNum` = `$cb_t1`.`stringnum`, > `$cb_c18_TimeValue` = `$cb_t1`.`timevalue`, > `$cb_c19_IntNum` = `$cb_t1`.`intnum` > WHERE `$cb_c8_type` = 'smalla' > {code} > The way how WHERE criteria is being pushed (either column or LET variable reference) affects execution plan and prevents index scan in the latter case. (WHERE `$cb_t1`.`type` = 'smalla' vs. WHERE `$cb_c8_type` = 'smalla'). > (1) https://developer.couchbase.com/documentation/server/current/n1ql/n1ql-la... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5439) Batch removed during large internal materialization load

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5439?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5439. ----------------------------------- Fix Version/s: 10.3.4 11.0.2 Resolution: Done Updated the logic to avoid the secondary exception and to show the original error. > Batch removed during large internal materialization load > -------------------------------------------------------- > > Key: TEIID-5439 > URL: https://issues.jboss.org/browse/TEIID-5439 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1, 10.3.4, 11.0.2 > > > For a sufficiently large materialization, such as 33000000 rows by 10 columns of biginteger/string types, the load will not complete and instead produce an exception: > {code} > ERROR: TEIID30019 Unexpected exception for request yGKKEfVoiD5O.0 > org.teiid.core.TeiidRuntimeException: Batch removed > at org.teiid.query.tempdata.TempTableDataManager.rethrow(TempTableDataManager.java:880) > at org.teiid.query.tempdata.TempTableDataManager.access$800(TempTableDataManager.java:92) > at org.teiid.query.tempdata.TempTableDataManager$4.load(TempTableDataManager.java:625) > at org.teiid.query.tempdata.TempTableDataManager$4.createTupleSource(TempTableDataManager.java:548) > at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:108) > at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:401) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) > at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:141) > at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:148) > at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:111) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:142) > at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:492) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5440) Couchbase translator - LET usage prevents index scan

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5440?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5440. ----------------------------------- Fix Version/s: 11.1 Resolution: Done Reworked the logic so that let is only used for array position expressions as it seems like all column references and meta usage do not require a let. > Couchbase translator - LET usage prevents index scan > ---------------------------------------------------- > > Key: TEIID-5440 > URL: https://issues.jboss.org/browse/TEIID-5440 > Project: Teiid > Issue Type: Quality Risk > Components: Misc. Connectors > Affects Versions: 8.12.14.6_4 > Reporter: Jan Stastny > Assignee: Steven Hawkins > Priority: Critical > Fix For: 11.1 > > > Couchbase translator excesively uses LET clause(1) just for purpose of naming columns. > That's not correct usage of LET clause and affects query execution in couchbase. > Simple query > {code:sql} > SELECT IntKey FROM SmallA; > {code} > is being pushed as > {code:sql} > SELECT `$cb_c1_IntKey` c1 FROM `dvqe` `$cb_t1` LET `$cb_c1_IntKey` = `$cb_t1`.`intkey` WHERE `$cb_t1`.`type` = 'smalla' > {code} > Which is fine and index on `type` column is scanned on couchbase side. > But when I issue query > {code:sql} > SELECT * FROM SmallA; > {code} > it is pushed as > {code:sql} > SELECT > `$cb_c1_documentID` c1, > `$cb_c2_FloatNum` c2, > `$cb_c3_IntKey` c3, > `$cb_c4_BigIntegerValue` c4, > `$cb_c5_StringKey` c5, > `$cb_c6_CharValue` c6, > `$cb_c7_LongNum` c7, > `$cb_c8_type` c8, > `$cb_c9_DoubleNum` c9, > `$cb_c10_ObjectValue` c10, > `$cb_c11_ShortValue` c11, > `$cb_c12_BigDecimalValue` c12, > `$cb_c13_DateValue` c13, > `$cb_c14_BooleanValue` c14, > `$cb_c15_TimestampValue` c15, > `$cb_c16_ByteNum` c16, > `$cb_c17_StringNum` c17, > `$cb_c18_TimeValue` c18, > `$cb_c19_IntNum` c19 > FROM `dvqe` `$cb_t1` > LET `$cb_c1_documentID` = META(`$cb_t1`).id, > `$cb_c2_FloatNum` = `$cb_t1`.`floatnum`, > `$cb_c3_IntKey` = `$cb_t1`.`intkey`, > `$cb_c4_BigIntegerValue` = `$cb_t1`.`bigintegervalue`, > `$cb_c5_StringKey` = `$cb_t1`.`stringkey`, > `$cb_c6_CharValue` = `$cb_t1`.`charvalue`, > `$cb_c7_LongNum` = `$cb_t1`.`longnum`, > `$cb_c8_type` = `$cb_t1`.`type`, > `$cb_c9_DoubleNum` = `$cb_t1`.`doublenum`, > `$cb_c10_ObjectValue` = `$cb_t1`.`objectvalue`, > `$cb_c11_ShortValue` = `$cb_t1`.`shortvalue`, > `$cb_c12_BigDecimalValue` = `$cb_t1`.`bigdecimalvalue`, > `$cb_c13_DateValue` = `$cb_t1`.`datevalue`, > `$cb_c14_BooleanValue` = `$cb_t1`.`booleanvalue`, > `$cb_c15_TimestampValue` = `$cb_t1`.`timestampvalue`, > `$cb_c16_ByteNum` = `$cb_t1`.`bytenum`, > `$cb_c17_StringNum` = `$cb_t1`.`stringnum`, > `$cb_c18_TimeValue` = `$cb_t1`.`timevalue`, > `$cb_c19_IntNum` = `$cb_t1`.`intnum` > WHERE `$cb_c8_type` = 'smalla' > {code} > The way how WHERE criteria is being pushed (either column or LET variable reference) affects execution plan and prevents index scan in the latter case. (WHERE `$cb_t1`.`type` = 'smalla' vs. WHERE `$cb_c8_type` = 'smalla'). > (1) https://developer.couchbase.com/documentation/server/current/n1ql/n1ql-la... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5425) Concurrency/timing issues observed with travis builds

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5425?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5425: ---------------------------------- Description: Several unit tests have been observed to fail during travis builds occasionally: 1. TestODBCSocketTransport.testRegClass:757 Â» PSQL ResultSet not positioned prope... 2. TestExternalMatViews.testLazyUpdate:930 expected:<2> but was:<1> (see https://api.travis-ci.org/v3/job/405801976/log.txt) 3. [ERROR] TestLocalConnections.testWaitForLoadTimeout:475 4. From https://api.travis-ci.org/v3/job/415138409/log.txt [ERROR] testReplication(org.teiid.systemmodel.TestReplication) Time elapsed: 35.21 s <<< FAILURE! java.lang.AssertionError: expected:<0.9164140964242746> but was:<0.18750528722359294> at org.teiid.systemmodel.TestReplication.testReplication(TestReplication.java:122) was: Several unit tests have been observed to fail during travis builds occasionally: TestODBCSocketTransport.testRegClass:757 Â» PSQL ResultSet not positioned prope... and TestExternalMatViews.testLazyUpdate:930 expected:<2> but was:<1> (see https://api.travis-ci.org/v3/job/405801976/log.txt) [ERROR] TestLocalConnections.testWaitForLoadTimeout:475 > Concurrency/timing issues observed with travis builds > ----------------------------------------------------- > > Key: TEIID-5425 > URL: https://issues.jboss.org/browse/TEIID-5425 > Project: Teiid > Issue Type: Bug > Components: Build/Kits > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > Several unit tests have been observed to fail during travis builds occasionally: > 1. TestODBCSocketTransport.testRegClass:757 Â» PSQL ResultSet not positioned prope... > 2. TestExternalMatViews.testLazyUpdate:930 expected:<2> but was:<1> (see https://api.travis-ci.org/v3/job/405801976/log.txt) > 3. [ERROR] TestLocalConnections.testWaitForLoadTimeout:475 > 4. From https://api.travis-ci.org/v3/job/415138409/log.txt > [ERROR] testReplication(org.teiid.systemmodel.TestReplication) Time elapsed: 35.21 s <<< FAILURE! > java.lang.AssertionError: expected:<0.9164140964242746> but was:<0.18750528722359294> > at org.teiid.systemmodel.TestReplication.testReplication(TestReplication.java:122) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5442) statistic function support for NTILE

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5442?page=com.atlassian.jira.plugin... ] Work on TEIID-5442 started by Steven Hawkins. --------------------------------------------- > statistic function support for NTILE > ------------------------------------ > > Key: TEIID-5442 > URL: https://issues.jboss.org/browse/TEIID-5442 > Project: Teiid > Issue Type: Feature Request > Components: Common > Reporter: Norbert Funke > Assignee: Steven Hawkins > > As a SQL developer, I like to be able to issue queries using NTILE functions such as > {{SELECT id, zip5, > ntile(100) OVER(ORDER BY geopgraphy) as percentile > FROM svi2105_us_zip5.svi2015_us_zip5;}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5394) Define how to utilize multiple vdbs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5394?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5394: --------------------------------------- > I was thinking to load each VDB file then, using MetadataFactory write back a single VDB out. If you are suggesting to do that at runtime, that's not much different than what I'm suggesting. > Even otherwise, I think we can/should impose rules how vdb-import works, like it must have separate ddl files etc, as it is an advanced feature. The components of a vdb for vdb import purposes are: main .xml or .ddl - containing schema, translator, and optional role information schema ddl and secondary artifacts yaml configuration Are you thinking we would restrict the import to only the schema ddl? Seems like that will require the redefinition of a lot of the other possible information. > The yaml files are not part of the VDB artifact. You may want to alter the current behavior. See the .vdb from rdbms-as-datasource, it will contain the yaml as described above. Also a .ddl file is not covered by the maven plugin logic. Was that intentional? > Define how to utilize multiple vdbs > ----------------------------------- > > Key: TEIID-5394 > URL: https://issues.jboss.org/browse/TEIID-5394 > Project: Teiid > Issue Type: Sub-task > Components: Build/Kits > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 11.1 > > > Perhaps to support vdb imports, we should define how a build can incorporate multiple vdbs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5442) statistic function support for NTILE

by Norbert Funke (JIRA)

Norbert Funke created TEIID-5442: ------------------------------------ Summary: statistic function support for NTILE Key: TEIID-5442 URL: https://issues.jboss.org/browse/TEIID-5442 Project: Teiid Issue Type: Feature Request Components: Common Reporter: Norbert Funke Assignee: Steven Hawkins As a SQL developer, I like to be able to issue queries using NTILE functions such as {{SELECT id, zip5, ntile(100) OVER(ORDER BY geopgraphy) as percentile FROM svi2105_us_zip5.svi2015_us_zip5;}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5441) Redshift translator "AS decimal" should have 0 default scale

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-5441?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-5441: --------------------------------- Fix Version/s: 8.12.15.6_4 > Redshift translator "AS decimal" should have 0 default scale > ------------------------------------------------------------ > > Key: TEIID-5441 > URL: https://issues.jboss.org/browse/TEIID-5441 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.12.14.6_4 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 11.1, 10.3.4, 11.0.2, 8.12.15.6_4 > > > Currently "AS decimal" relies on the posgresql behavior of using a non-zero default scale: https://www.postgresql.org/docs/10/static/datatype-numeric.html > Whereas redshift has a 0 default: https://docs.aws.amazon.com/redshift/latest/dg/r_Numeric_types201.html > So this needs updated in the base postgresql translator to work correctly on redshift. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5441) Redshift translator "AS decimal" should have 0 default scale

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5441?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5441. ----------------------------------- Fix Version/s: 11.1 10.3.4 11.0.2 Resolution: Done Updated the decimal cast to have explicit precision and scale. > Redshift translator "AS decimal" should have 0 default scale > ------------------------------------------------------------ > > Key: TEIID-5441 > URL: https://issues.jboss.org/browse/TEIID-5441 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.12.14.6_4 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 11.1, 10.3.4, 11.0.2 > > > Currently "AS decimal" relies on the posgresql behavior of using a non-zero default scale: https://www.postgresql.org/docs/10/static/datatype-numeric.html > Whereas redshift has a 0 default: https://docs.aws.amazon.com/redshift/latest/dg/r_Numeric_types201.html > So this needs updated in the base postgresql translator to work correctly on redshift. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues August 2018