March 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5624) Implement LO function support for pg/ODBC

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5624?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5624: --------------------------------------- This is difficult for us to map to... There is no such thing as an ephemeral lob for pg. It has to be when you select a lob from a table, you are actually getting the oid. We have effectively ephemeral lobs scoped to the resultset. A way to make this work is to provide some mapping of lob (resultset/streaming id) to an integer lob id. Then we'd use that as the id for lo_open and provide another integer id as the file descriptor for the open lob. However clients that don't support lo or aren't specifically expecting Teiid behavior will need to be able to turn off this behavior and get the equivalent bytea and text values. We may not be able to simply reuse the internal streaming id as we do inline our lobs - or I'd need to add turn that off on a per session/basis. > Implement LO function support for pg/ODBC > ----------------------------------------- > > Key: TEIID-5624 > URL: https://issues.jboss.org/browse/TEIID-5624 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > The current logic maps lobs to bytea and text types and caps their length by default to 2MB. We should add actual lob support using the LO functions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5694) Create a sub-module for geo functions

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5694: ------------------------------------- Summary: Create a sub-module for geo functions Key: TEIID-5694 URL: https://issues.jboss.org/browse/TEIID-5694 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 12.2 When not including the geo functionality we should see an warning, but not fail to start. The current logic will fail to start by looking directly at geometryutils to load the st_extent aggregate. It will also not fail to load the other function methods as Geo*FunctionMethods is isolated from the missing dependencies. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5624) Implement LO function support for pg/ODBC

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5624?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5624: --------------------------------------- Using the pg jdbc client for reference we need lo_open loread lo_close lo_lseek to implement read-only lobs. The pg_proc table will need to be updated with these methods. The easiest way to do that is to add pg_catalog functions to the pg_proc table. The full function sub-protocol will need to be implemented, but we can restrict to only these functions. > Implement LO function support for pg/ODBC > ----------------------------------------- > > Key: TEIID-5624 > URL: https://issues.jboss.org/browse/TEIID-5624 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > The current logic maps lobs to bytea and text types and caps their length by default to 2MB. We should add actual lob support using the LO functions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5624) Implement LO function support for pg/ODBC

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5624?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5624: --------------------------------------- To emulate this behavior we need to have something like - pg_largeobject such that we assign stable oids to lob results that can then be used to look them up in the largeobject table. It seems like we'll have to implement this on a ephemeral basis - that is for a single result it will have a set of lob oids, rather than attempting to assign oids all the way down to the source table level. > Implement LO function support for pg/ODBC > ----------------------------------------- > > Key: TEIID-5624 > URL: https://issues.jboss.org/browse/TEIID-5624 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > The current logic maps lobs to bytea and text types and caps their length by default to 2MB. We should add actual lob support using the LO functions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5692) Scaling float/double to bigdecimal/numeric is not always necessary

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5692?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5692. ----------------------------------- Resolution: Done Generally speaking the old behavior was attempting to preserve the approximate type scale - but that is not necessary and at worst creates values where the scale is much larger than expected. org.teiid.preserveApproximateScale was added as a system/environment property should this need to be toggled to the old behavior. It doesn't seem necessary at this point to make this a documented property. > Scaling float/double to bigdecimal/numeric is not always necessary > ------------------------------------------------------------------ > > Key: TEIID-5692 > URL: https://issues.jboss.org/browse/TEIID-5692 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > There is logic in the FloatingNumberToBigDecimalTransform to set the scale of the result bigdecimal to something representative of the scale of a float/double. However the way that java represents precision/scale of small and large value - for example 0.0d becomes 0E-15 after the transformation - implies more precision or scale than expected. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5686) NPE in MergeJoinStrategy when using joins with a particular limit value

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5686?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5686: --------------------------------------- Thanks for checking back [~dalex005] > NPE in MergeJoinStrategy when using joins with a particular limit value > ----------------------------------------------------------------------- > > Key: TEIID-5686 > URL: https://issues.jboss.org/browse/TEIID-5686 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 12.0 > Environment: teiid-12.0.0 on WildFly Full 14.0.1.Final (WildFly Core 6.0.2.Final) > Reporter: dalex dalex > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > When running the following query (IMPORTANT: you shouldn't use row limit): > {code:sql} > begin > declare integer i=0; > while (i < 2) > begin > select * > from "test_tables_pg.test_a" t0 > JOIN "test_tables_pg.test_e" t1 > ON true > JOIN "test_tables_pg.test_e" t2 > ON true > JOIN views.v t3 > on true > JOIN views.v t4 > on true > limit 257 ; > i=i+1; > end > end ;; > {code} > teiid throws out the following NPE: > {code:noformat} > 2019-03-13 13:50:28,582 ERROR [org.teiid.PROCESSOR] (Worker4_QueryProcessorQueue233) InwGU8fhfbja TEIID30019 Unexpected exception for request InwGU8fhfbja.22: java.lang.NullPointerEx > ception > at org.teiid.query.processor.relational.MergeJoinStrategy.compareToPrevious(MergeJoinStrategy.java:284) > at org.teiid.query.processor.relational.MergeJoinStrategy.process(MergeJoinStrategy.java:238) > at org.teiid.query.processor.relational.JoinNode.nextBatchDirectInternal(JoinNode.java:260) > at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:195) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) > at org.teiid.query.processor.relational.LimitNode.nextBatchDirect(LimitNode.java:98) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) > at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) > 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.BatchIterator.finalRow(BatchIterator.java:65) > at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:66) > at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:80) > at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:44) > at org.teiid.query.processor.proc.ProcedurePlan.nextBatchDirect(ProcedurePlan.java:303) > at org.teiid.query.processor.proc.ProcedurePlan.nextBatch(ProcedurePlan.java:269) > 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) > at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:362) > at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:43) > at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:285) > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:281) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:113) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:199) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5693) Ordering by two expressions results in the wrong odata query

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5693?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5693. ----------------------------------- Fix Version/s: 12.2 Resolution: Done Limited the aliasing to only the subquery case and added logic to produce unique aliases. > Ordering by two expressions results in the wrong odata query > ------------------------------------------------------------ > > Key: TEIID-5693 > URL: https://issues.jboss.org/browse/TEIID-5693 > Project: Teiid > Issue Type: Bug > Components: OData > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > Ordering by two non-column reference expressions: > $orderby=e2 mul 2,e2 mul 1 > will result in a query that has two dervied columns with the name _orderByAlias -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3522) Provide Data Aggregation Extension to OData V4

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-3522?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3522: --------------------------------------- [~rareddy] This will take a good bit of effort. I'm just now to supporting top level aggregates, effectively "select agg(x) from ..." without a group by. I haven't ensured that it works over cross joins, or with other standard query options. The olingo changes to support just this so far are: https://github.com/shawkins/olingo-odata4/commit/76ebd8886444893dd6cbfccd... The Teiid changes, that are a work in progress are: https://github.com/shawkins/teiid/tree/TEIID-3522 and in particular the commit: https://github.com/shawkins/teiid/commit/a6c568b2b3f7a24d9f89bedf3ddd902a... > Provide Data Aggregation Extension to OData V4 > ---------------------------------------------- > > Key: TEIID-3522 > URL: https://issues.jboss.org/browse/TEIID-3522 > Project: Teiid > Issue Type: Feature Request > Components: OData > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > OData V4 specification defines extension for Data Aggregation http://docs.oasis-open.org/odata/odata-data-aggregation-ext/v4.0/cs01/oda... > Teiid should provide support for this extension. There is Olingo support on this yet. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5693) Ordering by two expressions results in the wrong odata query

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5693: ------------------------------------- Summary: Ordering by two expressions results in the wrong odata query Key: TEIID-5693 URL: https://issues.jboss.org/browse/TEIID-5693 Project: Teiid Issue Type: Bug Components: OData Reporter: Steven Hawkins Assignee: Steven Hawkins Ordering by two non-column reference expressions: $orderby=e2 mul 2,e2 mul 1 will result in a query that has two dervied columns with the name _orderByAlias -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5692) Scaling float/double to bigdecimal/numeric is not always necessary

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5692: ------------------------------------- Summary: Scaling float/double to bigdecimal/numeric is not always necessary Key: TEIID-5692 URL: https://issues.jboss.org/browse/TEIID-5692 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 12.2 There is logic in the FloatingNumberToBigDecimalTransform to set the scale of the result bigdecimal to something representative of the scale of a float/double. However the way that java represents precision/scale of small and large value - for example 0.0d becomes 0E-15 after the transformation - implies more precision or scale than expected. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2019