January 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2367) sql server / sybase dependent parameter defaults too high

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2367: ------------------------------------- Summary: sql server / sybase dependent parameter defaults too high Key: TEIID-2367 URL: https://issues.jboss.org/browse/TEIID-2367 Project: Teiid Issue Type: Feature Request Components: JDBC Connector Affects Versions: 7.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.3 Our defaults for sybase/sql server are too high. Sybase is typically limited to 2048 entries (although it looks like the latest adaptive server may be 32k). While sql server should be 2100. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2361) The current MAX String size is 4000, add the ability to configure when larger sizes are used

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2361?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2361. ----------------------------------- Fix Version/s: 8.3 Resolution: Done Added a system property, which is documented in the admin guide, to control the max string length setting. This may also adjust the max lob memory bytes to a value that is similarly sized. > The current MAX String size is 4000, add the ability to configure when larger sizes are used > -------------------------------------------------------------------------------------------- > > Key: TEIID-2361 > URL: https://issues.jboss.org/browse/TEIID-2361 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 8.3 > > > The MAX String size is currently 4000. After a discussion with Steve, he indicated a more common default might be 16k, and also add the ability to configure the size when a data source is being used that contains large sizes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2363) proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2363?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2363. ----------------------------------- Resolution: Done Corrected the handling when the prefetch is cleared (when all the results are buffered) so that the iterator position is maintained. > proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)" > ----------------------------------------------------------------------------------------------------------- > > Key: TEIID-2363 > URL: https://issues.jboss.org/browse/TEIID-2363 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.7.2 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 8.3 > > > The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side > For inner joins there is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven for non-dependent non-outer joins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2363) proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2363?page=com.atlassian.jira.plugin... ] Steven Hawkins reopened TEIID-2363: ----------------------------------- Some additional changes are needed as there is a timing issue regression in TestDQPCore.testBufferReuse > proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)" > ----------------------------------------------------------------------------------------------------------- > > Key: TEIID-2363 > URL: https://issues.jboss.org/browse/TEIID-2363 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.7.2 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 8.3 > > > The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side > For inner joins there is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven for non-dependent non-outer joins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2063) NPE with proc relational query

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2063?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2063: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 885095|https://bugzilla.redhat.com/show_bug.cgi?id=885095] from ON_QA to VERIFIED > NPE with proc relational query > ------------------------------ > > Key: TEIID-2063 > URL: https://issues.jboss.org/browse/TEIID-2063 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.4, 7.7.3 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.1 > > > A proc relational query using a table function or other source without an access node will fail with an NPE, for example: > select param1, param2, e1, e2 from pm1.vsp26 as x, texttable('abc' columns a string) as y where param1=1 and param2='a' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2063) NPE with proc relational query

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2063?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2063: ------------------------------------------------ Filip Elias <felias(a)redhat.com> made a comment on [bug 885095|https://bugzilla.redhat.com/show_bug.cgi?id=885095] Verified on SOA-P 5.3.1 ER4. > NPE with proc relational query > ------------------------------ > > Key: TEIID-2063 > URL: https://issues.jboss.org/browse/TEIID-2063 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.4, 7.7.3 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.1 > > > A proc relational query using a table function or other source without an access node will fail with an NPE, for example: > select param1, param2, e1, e2 from pm1.vsp26 as x, texttable('abc' columns a string) as y where param1=1 and param2='a' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2363) proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2363?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2363. ----------------------------------- Fix Version/s: 8.3 Resolution: Done Modified the join logic to ensure that both sides of the join are processed as fully as possible in the presence of blocked exceptions. In the exact case raised by this issue the ALREADY_SORTED side will default to a 10 batch prefetch (which will likely be buffered to disk). The org.teiid.joinPrefetchBatches system property was added and doc'ed in the Admin Guide to increase that batch limit - which is appropriate for large joins where one side is being sorted and the other ALREADY_SORTED side is relatively slow. > proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)" > ----------------------------------------------------------------------------------------------------------- > > Key: TEIID-2363 > URL: https://issues.jboss.org/browse/TEIID-2363 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.7.2 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 8.3 > > > The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side > For inner joins there is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven for non-dependent non-outer joins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2366) If where clause contains both equal and greater then conditions then query may return no results

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2366?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2366. ----------------------------------- Labels: query, where (was: query where) Resolution: Done You are correct about where the issue (that cc, not cc1 should to be passed into the evaluation) lay. That has been corrected and also ensured that single item IN predicates are returned as equality, which is generally a contract that the rewrite maintains. > If where clause contains both equal and greater then conditions then query may return no results > ------------------------------------------------------------------------------------------------ > > Key: TEIID-2366 > URL: https://issues.jboss.org/browse/TEIID-2366 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.4 > Reporter: Paul Lysak > Assignee: Steven Hawkins > Labels: query,, where > Fix For: 8.3 > > > If WHERE clause contains '>' and '=' conditions for the same field then query may produce no result - depending on conditions order. > The problem seems to be in org.teiid.query.rewriter.QueryRewriter class, method rewriteAndConjunct(). Pay attention to following piece of code: > ... if (cc1.getOperator() == CompareCriteria.EQ) { > if (!Evaluator.compare(cc1, ((Constant)cc1.getRightExpression()).getValue(), ((Constant)cc.getRightExpression()).getValue())) { > return FALSE_CRITERIA; > } > Note that cc1 (which is guaranteed to have EQ criterion) is passed to Evaluator.compare. Thus right expressions of cc and cc1 are required to be equal. But if we have one contition EQ and another GT then it should instead check if right side of EQ is bigger then right side of GT. > Bug TEIID-1704 describes a bit similar situation but it is still a different case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2366) If where clause contains both equal and greater then conditions then query may return no results

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2366?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2366: ---------------------------------- Fix Version/s: 8.3 Labels: query where (was: query select where) Affects Version/s: 7.4 (was: 8.2) Complexity: Low > If where clause contains both equal and greater then conditions then query may return no results > ------------------------------------------------------------------------------------------------ > > Key: TEIID-2366 > URL: https://issues.jboss.org/browse/TEIID-2366 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.4 > Reporter: Paul Lysak > Assignee: Steven Hawkins > Labels: query, where > Fix For: 8.3 > > > If WHERE clause contains '>' and '=' conditions for the same field then query may produce no result - depending on conditions order. > The problem seems to be in org.teiid.query.rewriter.QueryRewriter class, method rewriteAndConjunct(). Pay attention to following piece of code: > ... if (cc1.getOperator() == CompareCriteria.EQ) { > if (!Evaluator.compare(cc1, ((Constant)cc1.getRightExpression()).getValue(), ((Constant)cc.getRightExpression()).getValue())) { > return FALSE_CRITERIA; > } > Note that cc1 (which is guaranteed to have EQ criterion) is passed to Evaluator.compare. Thus right expressions of cc and cc1 are required to be equal. But if we have one contition EQ and another GT then it should instead check if right side of EQ is bigger then right side of GT. > Bug TEIID-1704 describes a bit similar situation but it is still a different case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2366) If where clause contains both equal and greater then conditions then query may return no results

by Paul Lysak (JIRA)

[ https://issues.jboss.org/browse/TEIID-2366?page=com.atlassian.jira.plugin... ] Paul Lysak updated TEIID-2366: ------------------------------ Description: If WHERE clause contains '>' and '=' conditions for the same field then query may produce no result - depending on conditions order. The problem seems to be in org.teiid.query.rewriter.QueryRewriter class, method rewriteAndConjunct(). Pay attention to following piece of code: ... if (cc1.getOperator() == CompareCriteria.EQ) { if (!Evaluator.compare(cc1, ((Constant)cc1.getRightExpression()).getValue(), ((Constant)cc.getRightExpression()).getValue())) { return FALSE_CRITERIA; } Note that cc1 (which is guaranteed to have EQ criterion) is passed to Evaluator.compare. Thus right expressions of cc and cc1 are required to be equal. But if we have one contition EQ and another GT then it should instead check if right side of EQ is bigger then right side of GT. Bug TEIID-1704 describes a bit similar situation but it is still a different case. was: If WHERE clause contains '>' and '=' conditions for the same field then query may produce no result - depending on conditions order. The problem seems to be in org.teiid.query.rewriter.QueryRewriter class, method rewriteAndConjunct(). Pay attention to following piece of code: ... if (cc1.getOperator() == CompareCriteria.EQ) { if (!Evaluator.compare(cc1, ((Constant)cc1.getRightExpression()).getValue(), ((Constant)cc.getRightExpression()).getValue())) { return FALSE_CRITERIA; } Note that cc1 (which is guaranteed to have EQ criterion) is passed to Evaluator.compare. Thus right expressions of cc and cc1 are required to be equal. But if we have one contition EQ and another GT then it should instead check if right side of EQ is bigger then right side of GT. > If where clause contains both equal and greater then conditions then query may return no results > ------------------------------------------------------------------------------------------------ > > Key: TEIID-2366 > URL: https://issues.jboss.org/browse/TEIID-2366 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.2 > Reporter: Paul Lysak > Assignee: Steven Hawkins > Labels: query, select, where > > If WHERE clause contains '>' and '=' conditions for the same field then query may produce no result - depending on conditions order. > The problem seems to be in org.teiid.query.rewriter.QueryRewriter class, method rewriteAndConjunct(). Pay attention to following piece of code: > ... if (cc1.getOperator() == CompareCriteria.EQ) { > if (!Evaluator.compare(cc1, ((Constant)cc1.getRightExpression()).getValue(), ((Constant)cc.getRightExpression()).getValue())) { > return FALSE_CRITERIA; > } > Note that cc1 (which is guaranteed to have EQ criterion) is passed to Evaluator.compare. Thus right expressions of cc and cc1 are required to be equal. But if we have one contition EQ and another GT then it should instead check if right side of EQ is bigger then right side of GT. > Bug TEIID-1704 describes a bit similar situation but it is still a different case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2013