[JBoss JIRA] (TEIID-3623) HBase translator - boolean and biginteger values are not translated correctly
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3623?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3623:
----------------------------------
Fix Version/s: 8.7.1.6_2
> HBase translator - boolean and biginteger values are not translated correctly
> -----------------------------------------------------------------------------
>
> Key: TEIID-3623
> URL: https://issues.jboss.org/browse/TEIID-3623
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: Hbase: 1.1.1
> Phoenix: 4.5.0-HBase-1.1
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2, 8.12
>
> Attachments: insert_biginteger.log, inser_boolean.log
>
>
> *1. Boolean values:* The Teiid translates the value true/false as 1/0, but HBase does not support integer representation of boolean values [1].
> *2. BigInteger values ( <= -2):* Teiid's bigInteger data type is wider than HBase's bigint (as wide as long) type, so it make sense to define column in HBase as e.g. _decimal(30,0)_ and map it to Teiid's biginteger type.
> From Teiid's point of view: There is no problem if inserted value is greater than or equal to -1. But if the value is less than -1, then a ClassCastException is thrown [2]. Phoenix driver require something like "UPSERT INTO smalla (intkey, bigintegervalue) VALUES (1, -10 *.0*)"
> [1]
> *Query:* insert into hbase.smalla (intkey, booleanvalue) values (55, true)
> *Column definition:*
> - source: booleanvalue boolean
> - VDB: BooleanValue boolean OPTIONS (nameinsource 'booleanvalue', NATIVE_TYPE 'boolean')
> *Stack trace:*
> insert_boolean.log
> [2]
> *Query:* insert into hbase.smalla (intkey, bigintegervalue) values (55, -10)
> *Column definition:*
> - source: bigintegervalue decimal(20,0)
> - VDB: BigIntegerValue biginteger OPTIONS (nameinsource 'bigintegervalue', NATIVE_TYPE 'decimal')
> *Stack trace:*
> insert_biginteger.log
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3640) Improper initialization when memory buffer size is over 2 GB.
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3640:
-------------------------------------
Summary: Improper initialization when memory buffer size is over 2 GB.
Key: TEIID-3640
URL: https://issues.jboss.org/browse/TEIID-3640
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 8.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Critical
Fix For: 8.12
When the memory buffer size is over 2 GB, the initialization will not be correct as the number of segments is determined by a number that has been narrowed to an int.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3616) HBase translator - NPE if date value is 'null'
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3616?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3616:
----------------------------------
Fix Version/s: 8.7.1.6_2
> HBase translator - NPE if date value is 'null'
> ----------------------------------------------
>
> Key: TEIID-3616
> URL: https://issues.jboss.org/browse/TEIID-3616
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: Hbase: 1.1.1
> Phoenix: 4.5.0-HBase-1.1
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2, 8.12
>
> Attachments: log
>
>
> If the source table in HBase contains a 'NULL' date value, Teiid throws an NPE. I did not encounter any NPE using org.apache.phoenix.jdbc.PhoenixDriver [1]. Other data types seem to be OK too.
> I have tried integer, char, varchar, float, double, tinyint, smallint, bigint, decimal, varbinary, boolean, time, date, timestamp.
> [1]
> Connection con = new org.apache.phoenix.jdbc.PhoenixDriver().connect("jdbc:phoenix:localhost", new Properties())
> ResultSet rs = con.createStatement().executeQuery("select datevalue from smalla");
> while(rs.next()){
> System.out.println(rs.getDate(1));
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3627:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1253660|https://bugzilla.redhat.com/show_bug.cgi?id=1253660] from NEW to ASSIGNED
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12, 8.11.3
>
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3627:
------------------------------------
Ok, added the following:
@TranslatorProperty(display="CompareCriteriaOrdered", description="If true, translator can support comparison criteria with the operator '=>' or '<=' ",advanced=true)
@Override
public boolean supportsCompareCriteriaOrdered() {
return supportsCompareCriteriaOrdered;
}
public boolean setSupportsCompareCriteriaOrdered(boolean supports) {
return supportsCompareCriteriaOrdered = supports;
}
And tested it by adding translator override to see the GE and LE pushed down:
<translator name="infinispan-cache-dsl1" type="infinispan-cache-dsl">
<property name="supportsCompareCriteriaOrdered" value="true"/>
</translator>
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12, 8.11.3
>
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3632) Performance issue retrieving data source and translator definitions through the AdminFactory
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIID-3632?page=com.atlassian.jira.plugin... ]
Barry LaFond updated TEIID-3632:
--------------------------------
Attachment: server_refresh_cli_log.txt
> Performance issue retrieving data source and translator definitions through the AdminFactory
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3632
> URL: https://issues.jboss.org/browse/TEIID-3632
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Ramesh Reddy
> Attachments: server_refresh_cli_log.txt
>
>
> Based on the issue described in TEIIDDES-2592, we discovered that connecting to a remote server that contained ~ 40 data sources required > 10 minutes to refresh the Server view in Teiid Designer. After some debugging it appeared that some of the current behavior in AdminFactory results multiple redundant CLI calls to retrieve intermediate information to compile even a simple list of data source names.
> In Teiid Designer, we modified our forked Admin8Factory to define a few cached sets of data that get cleared if data is changed by our ExecutionAdmin class for any created or deleted data sources.
> Note that Designer's Server management paradigm includes the requirement to view the DS/Translator/VDB contents on the server.
> So I'm assuming that there could be some benefit if Teiid AdminFactory adapted a similar approach to improving the performance/behavior of the internal methods of this class.
> see: https://github.com/Teiid-Designer/teiid-designer/blob/master/plugins/teii... for details
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3627:
------------------------------------
I would say yes. So with that being said, I need to create the methods with the @TranslatorProperty annotation and add the logic so that capability can be enabled/disabled, right?
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12, 8.11.3
>
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3627:
---------------------------------------
So would this need to be configurable in 62_8.7.x as well?
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12, 8.11.3
>
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3627:
------------------------------------
Yes, it is currently being looked into to see about getting a patch for JDG 6.4. And that would also mean they will need to patch 6.5, as that's what's targeted for DV 6.3.
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12, 8.11.3
>
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months