[JBoss JIRA] (TEIID-3929) Accumulo does not return null values
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-3929?page=com.atlassian.jira.plugin... ]
Jan Stastny reopened TEIID-3929:
--------------------------------
The problem is still there.
If I select only nullable column, there are no NULL values returned, even though they should. Such query:
{code:sql}
SELECT bytenum FROM bqt1.smalla;
{code} returns 47 rows.
When I add a column, which in fact is a mapped rowid from accumulo table, I get same number of results - no NULLs returned:
{code:sql}
SELECT intkey,bytenum FROM bqt1.smalla;
{code} returns 47 rows.
Even though the query on the 'rowid' column:
{code:sql}
SELECT intkey FROM bqt1.smallA;
{code} returns 50 rows.
But when I select with not nullable column (stringkey), which is not the rowid in accumulo, I get correct results.
{code:sql}
SELECT stringkey,bytenum FROM bqt1.smalla;
{code} returns 50 rows with null values.
> Accumulo does not return null values
> ------------------------------------
>
> Key: TEIID-3929
> URL: https://issues.jboss.org/browse/TEIID-3929
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> Accumulo doesn't return null values when a whole 'column' is being selected.
> For a command in accumulo shell like:
> {code:plain}
> scan -c name:BYTENUM
> {code}
> Accumulo returns only non-empty values, this is expected behaviour.
> Equivalent query in Teiid would be:
> {code:sql}
> SELECT ByteNum FROM SmallA
> {code}
> Which returns the same results as Accumulo does. That means, no NULL values, if there are rowids without specified column families/qualifiers missing. But when a user has his schema defined in a vdb, he probably expects, that he will get as many rows as there are in the table.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-4257) Nesting join parens cause H2 performance issue
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4257:
-------------------------------------
Summary: Nesting join parens cause H2 performance issue
Key: TEIID-4257
URL: https://issues.jboss.org/browse/TEIID-4257
Project: Teiid
Issue Type: Quality Risk
Components: JDBC Connector
Affects Versions: 8.12
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.1
The fix for TEIID-3549 introduced nesting parens on both the left and right side - but having the left nesting causes different optimization behavior for H2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3921) Accumulo translator doesn't end query execution when there are no tablet servers
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3921?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3921:
------------------------------------------------
Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1300987|https://bugzilla.redhat.com/show_bug.cgi?id=1300987] from ON_QA to VERIFIED
> Accumulo translator doesn't end query execution when there are no tablet servers
> --------------------------------------------------------------------------------
>
> Key: TEIID-3921
> URL: https://issues.jboss.org/browse/TEIID-3921
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> Teiid accumulo translator doesn't interrupt query execution when the accumulo instance is not running.
> There might be a situation that Zookeeper instance is running, but Accumulo is not.
> The translator, even though there is no tablet server entry in zookeeper, for given accumulo instance, executes the query. The query is running until query timeout exceeds. There is no indication of the fact, that accumulo tablet server is not present/responding except for
> {code}
> 09:25:46,539 WARN [org.apache.accumulo.core.client.impl.ServerClient] (Worker3_QueryProcessorQueue21) There are no tablet servers: check that zookeeper and accumulo are running.
> {code}
> There might be even situation, that Accumulo stopped in unusual way and didn't alter the tablet server information in Zookeeper, this way, there is a tablet server entry present in Zookeeper, but the tablet server is in fact not running. So Teiid should check the tablet server's address which received from Zookeeper.
> Interesting to note is the fact, that the same problem can be examined in accumulo's shell:
> {code}
> $ bin/accumulo shell -u root
> Password: ******
> 2016-01-22 10:02:05,604 [impl.ServerClient] WARN : There are no tablet servers: check that zookeeper and accumulo are running.
> {code}
> and then the shell hangs. Teiid needs to overcome this limitation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3842) Teiid's query's explain not consistence with other Database
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3842?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3842.
---------------------------------
> Teiid's query's explain not consistence with other Database
> ------------------------------------------------------------
>
> Key: TEIID-3842
> URL: https://issues.jboss.org/browse/TEIID-3842
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Kylin Soong
>
> h2. The way to get execution plan is not consistence with others
> For most of RDBMS(Oracle, Mysql), the execution plan get via SQL query
> {code}
> explain select ...
> {code}
> But in Teiid, we need use Teiid API, and need enable showplan in advance:
> {code}
> statement.execute("set showplan on");
> ResultSet rs = statement.executeQuery("select ...");
> TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
> PlanNode queryPlan = tstatement.getPlanDescription();
> System.out.println(queryPlan);
> {code}
> Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
> h2. The plan structure is too complex
> [1] is the query plan of dynamicvdb-datafederation which is 2 datasources' federation, it long, complex, for the users/customers, it's not easy for them to understand. So can we enhance that simplify the output, like add a format option that can output as matrix/table.
> [1] dynamicvdb-datafederation's 'select * from Stock' query plan
> {code}
> ProjectNode
> + Relational Node ID:0
> + Output Columns:
> 0: product_id (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: company_name (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:1
> + Output Columns:
> 0: ID (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 4
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:2
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 7
> 3: Node Cumulative Process Time: 7
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> ProjectNode
> + Relational Node ID:3
> + Output Columns:file (clob)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> AccessNode
> + Relational Node ID:4
> + Output Columns:
> 0: file (clob)
> 1: filePath (string)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:EXEC MarketData.getTextFiles('*.txt')
> + Model Name:MarketData
> + Select Columns:MarketData.getTextFiles.file
> + Child 1:
> TextTableNode
> + Relational Node ID:5
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 3
> 2: Node Cumulative Next Batch Process Time: 3
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Table Function:TEXTTABLE(f.file COLUMNS symbol string, price bigdecimal HEADER) AS SP
> + Join Strategy:NESTED TABLE JOIN
> + Join Type:CROSS JOIN
> + Join Criteria
> + Child 1:
> AccessNode
> + Relational Node ID:6
> + Output Columns:
> 0: SYMBOL (string)
> 1: ID (integer)
> 2: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 25
> 1: Node Next Batch Process Time: 1
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 17
> 4: Node Next Batch Calls: 5
> 5: Node Blocks: 4
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:SELECT g_0.SYMBOL AS c_0, g_0.ID AS c_1, g_0.COMPANY_NAME AS c_2 FROM Accounts.PRODUCT AS g_0 ORDER BY c_0
> + Model Name:Accounts
> + Join Strategy:ENHANCED SORT JOIN RAN AS SORT MERGE (SORT/ALREADY_SORTED)
> + Join Type:INNER JOIN
> + Join Criteria:SP.symbol=A.SYMBOL
> + Select Columns:
> 0: A.ID AS product_id
> 1: SP.symbol
> 2: SP.price
> 3: A.COMPANY_NAME AS company_name
> + Data Bytes Sent:0
> + Planning Time:128
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3842) Teiid's query's explain not consistence with other Database
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3842?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3842:
----------------------------------
Fix Version/s: (was: 9.x)
> Teiid's query's explain not consistence with other Database
> ------------------------------------------------------------
>
> Key: TEIID-3842
> URL: https://issues.jboss.org/browse/TEIID-3842
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Kylin Soong
>
> h2. The way to get execution plan is not consistence with others
> For most of RDBMS(Oracle, Mysql), the execution plan get via SQL query
> {code}
> explain select ...
> {code}
> But in Teiid, we need use Teiid API, and need enable showplan in advance:
> {code}
> statement.execute("set showplan on");
> ResultSet rs = statement.executeQuery("select ...");
> TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
> PlanNode queryPlan = tstatement.getPlanDescription();
> System.out.println(queryPlan);
> {code}
> Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
> h2. The plan structure is too complex
> [1] is the query plan of dynamicvdb-datafederation which is 2 datasources' federation, it long, complex, for the users/customers, it's not easy for them to understand. So can we enhance that simplify the output, like add a format option that can output as matrix/table.
> [1] dynamicvdb-datafederation's 'select * from Stock' query plan
> {code}
> ProjectNode
> + Relational Node ID:0
> + Output Columns:
> 0: product_id (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: company_name (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:1
> + Output Columns:
> 0: ID (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 4
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:2
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 7
> 3: Node Cumulative Process Time: 7
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> ProjectNode
> + Relational Node ID:3
> + Output Columns:file (clob)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> AccessNode
> + Relational Node ID:4
> + Output Columns:
> 0: file (clob)
> 1: filePath (string)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:EXEC MarketData.getTextFiles('*.txt')
> + Model Name:MarketData
> + Select Columns:MarketData.getTextFiles.file
> + Child 1:
> TextTableNode
> + Relational Node ID:5
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 3
> 2: Node Cumulative Next Batch Process Time: 3
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Table Function:TEXTTABLE(f.file COLUMNS symbol string, price bigdecimal HEADER) AS SP
> + Join Strategy:NESTED TABLE JOIN
> + Join Type:CROSS JOIN
> + Join Criteria
> + Child 1:
> AccessNode
> + Relational Node ID:6
> + Output Columns:
> 0: SYMBOL (string)
> 1: ID (integer)
> 2: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 25
> 1: Node Next Batch Process Time: 1
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 17
> 4: Node Next Batch Calls: 5
> 5: Node Blocks: 4
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:SELECT g_0.SYMBOL AS c_0, g_0.ID AS c_1, g_0.COMPANY_NAME AS c_2 FROM Accounts.PRODUCT AS g_0 ORDER BY c_0
> + Model Name:Accounts
> + Join Strategy:ENHANCED SORT JOIN RAN AS SORT MERGE (SORT/ALREADY_SORTED)
> + Join Type:INNER JOIN
> + Join Criteria:SP.symbol=A.SYMBOL
> + Select Columns:
> 0: A.ID AS product_id
> 1: SP.symbol
> 2: SP.price
> 3: A.COMPANY_NAME AS company_name
> + Data Bytes Sent:0
> + Planning Time:128
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3922) Accumulo translator needs defined dependency to "org.jboss.teiid" module
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3922?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3922:
------------------------------------------------
Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1301065|https://bugzilla.redhat.com/show_bug.cgi?id=1301065] from ON_QA to VERIFIED
> Accumulo translator needs defined dependency to "org.jboss.teiid" module
> ------------------------------------------------------------------------
>
> Key: TEIID-3922
> URL: https://issues.jboss.org/browse/TEIID-3922
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Jan Stastny
> Fix For: 8.13, 8.12.5
>
>
> When using Accumulo translator to query an accumulo instance, following exception appears, when comparing on a column.
> {code}
> Caused by: java.lang.ClassNotFoundException: org.teiid.api.exception.query.ExpressionEvaluationException
> {code}
> Example query:
> {code:sql}
> SELECT * FROM MyTable WHERE MyColumn='string';
> {code}
> The reason is, that the mentioned class ExpressionEvaluationException is placed in module "org.jboss.teiid", but this module is not set as dependency in resulting "org.jboss.teiid.translator.accumulo" module.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3930) Accumulo translator: select rowid returns empty resultset
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3930?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3930:
------------------------------------------------
Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1301540|https://bugzilla.redhat.com/show_bug.cgi?id=1301540] from ON_QA to VERIFIED
> Accumulo translator: select rowid returns empty resultset
> ---------------------------------------------------------
>
> Key: TEIID-3930
> URL: https://issues.jboss.org/browse/TEIID-3930
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> Accumulo translator, according to its [documentation|https://docs.jboss.org/author/display/teiid812final/Apache+...], enables querying accumulo through teiid's vdb with table like:
> {code:xml}
> CREATE FOREIGN TABLE "User" (
> rowid string OPTIONS (UPDATABLE FALSE, SEARCHABLE 'All_Except_Like'),
> name_age string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'age', "teiid_accumulo:VALUE-IN" '{VALUE}'),
> name_firstname string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'firstname', "teiid_accumulo:VALUE-IN" '{VALUE}'),
> name_lastname string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'lastname', "teiid_accumulo:VALUE-IN" '{VALUE}'),
> CONSTRAINT PK0 PRIMARY KEY(rowid)
> ) OPTIONS (UPDATABLE TRUE);
> {code}
> The problem is, that querying for rowid column won't return any results:
> Query
> {code:sql}
> SELECT rowid FROM User;
> {code}
> does return empty resultset.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3933) Accumulo translator: problem comparing number literals
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3933?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3933:
------------------------------------------------
Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1301665|https://bugzilla.redhat.com/show_bug.cgi?id=1301665] from ON_QA to VERIFIED
> Accumulo translator: problem comparing number literals
> ------------------------------------------------------
>
> Key: TEIID-3933
> URL: https://issues.jboss.org/browse/TEIID-3933
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> When accessing Accumulo instance using accumulo translator with table DDL defined in the model's metadata, there are problems filtering the output in from clause.
> For example, when there is a comparison between a column of type long with literal value 3, an exception, whose cause is below, is thrown on accumulo's side:
> {code:sql}
> SELECT * FROM accumulo.SmallA WHERE LongNum>3
> {code}
> {code:plain}
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
> at java.lang.Long.compareTo(Long.java:50)
> at org.teiid.query.sql.symbol.Constant$2.compare(Constant.java:99)
> at org.teiid.query.eval.Evaluator.compare(Evaluator.java:645)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:373)
> at org.teiid.query.eval.Evaluator.internalEvaluateTVL(Evaluator.java:237)
> at org.teiid.query.eval.Evaluator.evaluateTVL(Evaluator.java:226)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:220)
> at org.teiid.translator.accumulo.EvaluatorIterator.acceptRow(EvaluatorIterator.java:229)
> at org.teiid.translator.accumulo.EvaluatorIterator.filter(EvaluatorIterator.java:184)
> at org.teiid.translator.accumulo.EvaluatorIterator.prepKeys(EvaluatorIterator.java:180)
> at org.teiid.translator.accumulo.EvaluatorIterator.seek(EvaluatorIterator.java:159)
> at org.apache.accumulo.core.iterators.WrappingIterator.seek(WrappingIterator.java:101)
> at org.apache.accumulo.core.iterators.user.VersioningIterator.seek(VersioningIterator.java:81)
> at org.apache.accumulo.core.iterators.system.SourceSwitchingIterator.readNext(SourceSwitchingIterator.java:116)
> at org.apache.accumulo.core.iterators.system.SourceSwitchingIterator.seek(SourceSwitchingIterator.java:168)
> at org.apache.accumulo.server.tabletserver.Tablet.nextBatch(Tablet.java:1737)
> at org.apache.accumulo.server.tabletserver.Tablet.access$3200(Tablet.java:152)
> at org.apache.accumulo.server.tabletserver.Tablet$Scanner.read(Tablet.java:1879)
> at org.apache.accumulo.server.tabletserver.TabletServer$ThriftClientHandler$NextBatchTask.run(TabletServer.java:945)
> at org.apache.accumulo.trace.instrument.TraceRunnable.run(TraceRunnable.java:47)
> {code}
> but when I provide a value higher, than can be saved in integer, thus the type of the literal is inferred as long, the query runs as expected.
> {code:sql}
> SELECT * FROM accumulo.SmallA WHERE LongNum>30000000000000000000
> {code}
> Similar problems I had with
> ||Column type||Literal||Inferred type||Rootcause message||
> |long|3|Integer|java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long|
> |biginteger|3|Integer|java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigInteger|
> |double|3.0|BigDecimal|java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Double|
> |float|3.0|BigDecimal|java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Float|
> rest of the cause's stacktrace look the same.
> In Squirrel I get:
> {code:plain}
> TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 node-one: Error on server 127.0.0.1:9997
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-3944) Accumulo translator: rowid column is compared as string in WHERE clause
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3944?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3944:
------------------------------------------------
Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1302977|https://bugzilla.redhat.com/show_bug.cgi?id=1302977] from ON_QA to VERIFIED
> Accumulo translator: rowid column is compared as string in WHERE clause
> -----------------------------------------------------------------------
>
> Key: TEIID-3944
> URL: https://issues.jboss.org/browse/TEIID-3944
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> When in SOURCE model user specifies the required rowid column as integer:
> {code:xml}
> CREATE FOREIGN TABLE "SmallA" (
> rowid integer OPTIONS (UPDATABLE FALSE, SEARCHABLE 'All_Except_Like'),
> .
> .
> .
> {code}
> and performs similar query:
> {code:sql}
> Select rowid, StringKey From accumulo.SmallA WHERE rowid >= 15 ORDER BY rowid
> {code}
> following results are returned:
> || rowid | StringKey ||
> || 2 | 2 ||
> || 3 | 3 ||
> || 4 | 4 ||
> || 5 | 5 ||
> || 6 | 6 ||
> || 7 | 7 ||
> || 8 | 8 ||
> || 9 | 9 ||
> || 15 | 15 ||
> || ... | ... ||
> and given the fact, that rowid is modelled as integer, values 2,3,4,5,6,7,8,9 shouldn't appear in the result set. Interesting to note is that the resultset is then ordered by rowid, but this time correctly as expected.
> Other integer columns, mapped from accumulo's Column Family: Column Qualifier pairs works as expected and are being compared as corresponding types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (TEIID-4256) Hive translator - types in IN predicate should be of same type
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4256?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4256:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1343912
Bugzilla Update: Perform
> Hive translator - types in IN predicate should be of same type
> --------------------------------------------------------------
>
> Key: TEIID-4256
> URL: https://issues.jboss.org/browse/TEIID-4256
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.12.x
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> Teiid seems to not fully translate convert(..., date) expression. The source-specific command contains only string representation of the date. But hive treats this as string, not date.
> *SQL query:*
> {code:sql}
> SELECT BQT1.SmallA.IntKey FROM BQT1.SmallA WHERE BQT1.SmallA.DateValue IN (convert('2000-01-12', date), convert('2000-02-02', date))
> {code}
> *Source-specific command:*
> {code:sql}
> SELECT g_0.intkey AS c_0 FROM smalla g_0 WHERE g_0.datevalue IN ('2000-01-12', '2000-02-02')
> {code}
> *Exception:*
> {code:plain}
> 11:54:54,680 WARN [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue17) TEIID30020 Processing exception for request /2VwN2gwljfj.7 'TEIID30504 Source: 10014 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.intkey AS c_0 FROM smalla g_0 WHERE g_0.datevalue IN ('2000-01-12', '2000-02-02') LIMIT 100]'. Originally TeiidProcessingException 'org.apache.hadoop.hive.ql.parse.SemanticException:Line 1:61 Wrong arguments ''2000-02-02'': The arguments for IN should be the same type! Types are: {date IN (string, string)}' TypeCheckProcFactory.java:1324.: org.teiid.core.TeiidProcessingException: TEIID30504 Source: 10014 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.intkey AS c_0 FROM smalla g_0 WHERE g_0.datevalue IN ('2000-01-12', '2000-02-02') LIMIT 100]
> at org.teiid.dqp.internal.process.DataTierTupleSource.exceptionOccurred(DataTierTupleSource.java:401) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:161) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:391) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal]
> Caused by: org.teiid.translator.jdbc.JDBCExecutionException: 10014 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.intkey AS c_0 FROM smalla g_0 WHERE g_0.datevalue IN ('2000-01-12', '2000-02-02') LIMIT 100]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0-internal]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0-internal]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0-internal]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0-internal]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at com.sun.proxy.$Proxy47.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0-internal]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) [teiid-engine-8.12.5.redhat-5.jar:8.12.5.redhat-5]
> ... 6 more
> Caused by: org.apache.hive.service.cli.HiveSQLException: Error while compiling statement: FAILED: SemanticException [Error 10014]: Line 1:61 Wrong arguments ''2000-02-02'': The arguments for IN should be the same type! Types are: {date IN (string, string)}
> at org.apache.hive.jdbc.Utils.verifySuccess(Utils.java:258)
> at org.apache.hive.jdbc.Utils.verifySuccessWithInfo(Utils.java:244)
> at org.apache.hive.jdbc.HiveStatement.execute(HiveStatement.java:247)
> at org.apache.hive.jdbc.HiveStatement.executeQuery(HiveStatement.java:378)
> at org.apache.hive.jdbc.HivePreparedStatement.executeQuery(HivePreparedStatement.java:109)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:123)
> ... 18 more
> Caused by: org.apache.hive.service.cli.HiveSQLException: Error while compiling statement: FAILED: SemanticException [Error 10014]: Line 1:61 Wrong arguments ''2000-02-02'': The arguments for IN should be the same type! Types are: {date IN (string, string)}
> at org.apache.hive.service.cli.operation.Operation.toSQLException(Operation.java:315)
> at org.apache.hive.service.cli.operation.SQLOperation.prepare(SQLOperation.java:112)
> at org.apache.hive.service.cli.operation.SQLOperation.runInternal(SQLOperation.java:181)
> at org.apache.hive.service.cli.operation.Operation.run(Operation.java:257)
> at org.apache.hive.service.cli.session.HiveSessionImpl.executeStatementInternal(HiveSessionImpl.java:419)
> at org.apache.hive.service.cli.session.HiveSessionImpl.executeStatementAsync(HiveSessionImpl.java:406)
> at org.apache.hive.service.cli.CLIService.executeStatementAsync(CLIService.java:274)
> at org.apache.hive.service.cli.thrift.ThriftCLIService.ExecuteStatement(ThriftCLIService.java:486)
> at org.apache.hive.service.cli.thrift.TCLIService$Processor$ExecuteStatement.getResult(TCLIService.java:1317)
> at org.apache.hive.service.cli.thrift.TCLIService$Processor$ExecuteStatement.getResult(TCLIService.java:1302)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at org.apache.hive.service.auth.TSetIpAddressProcessor.process(TSetIpAddressProcessor.java:56)
> at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:285)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.8.0-internal]
> ... 1 more
> Caused by: java.lang.RuntimeException: org.apache.hadoop.hive.ql.parse.SemanticException:Line 1:61 Wrong arguments ''2000-02-02'': The arguments for IN should be the same type! Types are: {date IN (string, string)}
> at org.apache.hadoop.hive.ql.parse.TypeCheckProcFactory$DefaultExprProcessor.process(TypeCheckProcFactory.java:1324)
> at org.apache.hadoop.hive.ql.lib.DefaultRuleDispatcher.dispatch(DefaultRuleDispatcher.java:90)
> at org.apache.hadoop.hive.ql.lib.DefaultGraphWalker.dispatchAndReturn(DefaultGraphWalker.java:95)
> at org.apache.hadoop.hive.ql.lib.DefaultGraphWalker.dispatch(DefaultGraphWalker.java:79)
> at org.apache.hadoop.hive.ql.lib.DefaultGraphWalker.walk(DefaultGraphWalker.java:133)
> at org.apache.hadoop.hive.ql.lib.DefaultGraphWalker.startWalking(DefaultGraphWalker.java:110)
> at org.apache.hadoop.hive.ql.parse.TypeCheckProcFactory.genExprNode(TypeCheckProcFactory.java:213)
> at org.apache.hadoop.hive.ql.parse.TypeCheckProcFactory.genExprNode(TypeCheckProcFactory.java:157)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genAllExprNodeDesc(SemanticAnalyzer.java:10507)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genExprNodeDesc(SemanticAnalyzer.java:10463)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genExprNodeDesc(SemanticAnalyzer.java:10431)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genFilterPlan(SemanticAnalyzer.java:2818)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genFilterPlan(SemanticAnalyzer.java:2799)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genBodyPlan(SemanticAnalyzer.java:8848)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genPlan(SemanticAnalyzer.java:9743)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genPlan(SemanticAnalyzer.java:9636)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.genOPTree(SemanticAnalyzer.java:10109)
> at org.apache.hadoop.hive.ql.parse.CalcitePlanner.genOPTree(CalcitePlanner.java:329)
> at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.analyzeInternal(SemanticAnalyzer.java:10120)
> at org.apache.hadoop.hive.ql.parse.CalcitePlanner.analyzeInternal(CalcitePlanner.java:211)
> at org.apache.hadoop.hive.ql.parse.BaseSemanticAnalyzer.analyze(BaseSemanticAnalyzer.java:227)
> at org.apache.hadoop.hive.ql.Driver.compile(Driver.java:456)
> at org.apache.hadoop.hive.ql.Driver.compile(Driver.java:316)
> at org.apache.hadoop.hive.ql.Driver.compileInternal(Driver.java:1181)
> at org.apache.hadoop.hive.ql.Driver.compileAndRespond(Driver.java:1175)
> at org.apache.hive.service.cli.operation.SQLOperation.prepare(SQLOperation.java:110)
> ... 15 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months