[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098450#comment-15098450
]
Josh Elser commented on CALCITE-1052:
-
[~kliew], I'm not having any success with your docker container so far. It
seems to hang before ever starting PQS.
Can you drop me an email? (see the addr on my JIRA acct).
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int column1 = rs.getInt("column1");
> if (column1 != 2)
> {
>
[jira] [Updated] (CALCITE-1054) NPE caused by wrong code generation for Timestamp fields
[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frankie Bollaert updated CALCITE-1054:
--
Affects Version/s: 1.4.0-incubating
> NPE caused by wrong code generation for Timestamp fields
>
>
> Key: CALCITE-1054
> URL: https://issues.apache.org/jira/browse/CALCITE-1054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.0-incubating
>Reporter: Frankie Bollaert
>Assignee: Julian Hyde
>Priority: Minor
>
> Problem occurs when:
> - Execute a query containing 2 checks on a Timestamp field
> - Table contains records which have NULL values for this field
> Example query:
> {code}
> select * from aTable where aTimestamp > timestamp '2015-1-1 00:00:00' and
> aTimestamp < timestamp '2015-2-1 00:00:00';
> {code}
> {code}
> /* 48 */ public boolean moveNext() {
> /* 49 */ while (inputEnumerator.moveNext()) {
> /* 50 */ final java.sql.Timestamp inp23_ = (java.sql.Timestamp)
> ((Object[]) inputEnumerator.current())[23];
> /* 51 */ final long v =
> org.apache.calcite.runtime.SqlFunctions.toLong(inp23_);
> /* 52 */ if (inp23_ != null && v > 142007040L && (inp23_ != null
> && v < 142274880L)) {
> /* 53 */ return true;
> /* 54 */ }
> /* 55 */ }
> /* 56 */ return false;
> /* 57 */ }
> {code}
> Stack trace snippet
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1094)
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1089)
> at Baz$1$1.moveNext(ANONYMOUS.java:51)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:677)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:103)
> {code}
> The generated code also looks wrong for date fields.
> {code}
> /* 15 */ public boolean moveNext() {
> /* 16 */ while (inputEnumerator.moveNext()) {
> /* 17 */ final java.sql.Date current = (java.sql.Date)
> inputEnumerator.current();
> /* 18 */ final int v =
> org.apache.calcite.runtime.SqlFunctions.toInt(current);
> /* 19 */ if (current != null && v > 2780 && (current != null && v <
> 5290)) {
> /* 20 */ return true;
> /* 21 */ }
> /* 22 */ }
> /* 23 */ return false;
> /* 24 */ }
> {code}
> \\
> Other types of fields do not have this problem. Below is what the generated
> code looks like in the case of a String field. *On line 20 there is a null
> check.* This is the type of check that needs to be generated for Timestamp
> fields as well.
> {code}
> select empno from sales.emps where gender > 'A' and gender < 'Z';
> {code}
> {code}
> /* 17 */ public boolean moveNext() {
> /* 18 */while (inputEnumerator.moveNext()) {
> /* 19 */ final Object[] current = (Object[]) inputEnumerator.current();
> /* 20 */ final String inp3_ = current[3] == null ? (String) null :
> current[3].toString();
> /* 21 */ if (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.gt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_A_) && (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.lt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_Z_))) {
> /* 22 */return true;
> /* 23 */ }
> /* 24 */}
> /* 25 */return false;
> /* 26 */ }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1054) NPE caused by wrong code generation for Timestamp fields
[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098136#comment-15098136
]
Frankie Bollaert commented on CALCITE-1054:
---
Thank you Julian, your pointers are very helpful.
The snippets of generated code in this issue where created using Calcite 1.4.
Using the code of the git master branch produces a different result. If you
are not planning any 1.4 branch releases, then this issue is not relevant, and
may best be closed.
> NPE caused by wrong code generation for Timestamp fields
>
>
> Key: CALCITE-1054
> URL: https://issues.apache.org/jira/browse/CALCITE-1054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.0-incubating
>Reporter: Frankie Bollaert
>Assignee: Julian Hyde
>Priority: Minor
>
> Problem occurs when:
> - Execute a query containing 2 checks on a Timestamp field
> - Table contains records which have NULL values for this field
> Example query:
> {code}
> select * from aTable where aTimestamp > timestamp '2015-1-1 00:00:00' and
> aTimestamp < timestamp '2015-2-1 00:00:00';
> {code}
> {code}
> /* 48 */ public boolean moveNext() {
> /* 49 */ while (inputEnumerator.moveNext()) {
> /* 50 */ final java.sql.Timestamp inp23_ = (java.sql.Timestamp)
> ((Object[]) inputEnumerator.current())[23];
> /* 51 */ final long v =
> org.apache.calcite.runtime.SqlFunctions.toLong(inp23_);
> /* 52 */ if (inp23_ != null && v > 142007040L && (inp23_ != null
> && v < 142274880L)) {
> /* 53 */ return true;
> /* 54 */ }
> /* 55 */ }
> /* 56 */ return false;
> /* 57 */ }
> {code}
> Stack trace snippet
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1094)
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1089)
> at Baz$1$1.moveNext(ANONYMOUS.java:51)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:677)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:103)
> {code}
> The generated code also looks wrong for date fields.
> {code}
> /* 15 */ public boolean moveNext() {
> /* 16 */ while (inputEnumerator.moveNext()) {
> /* 17 */ final java.sql.Date current = (java.sql.Date)
> inputEnumerator.current();
> /* 18 */ final int v =
> org.apache.calcite.runtime.SqlFunctions.toInt(current);
> /* 19 */ if (current != null && v > 2780 && (current != null && v <
> 5290)) {
> /* 20 */ return true;
> /* 21 */ }
> /* 22 */ }
> /* 23 */ return false;
> /* 24 */ }
> {code}
> \\
> Other types of fields do not have this problem. Below is what the generated
> code looks like in the case of a String field. *On line 20 there is a null
> check.* This is the type of check that needs to be generated for Timestamp
> fields as well.
> {code}
> select empno from sales.emps where gender > 'A' and gender < 'Z';
> {code}
> {code}
> /* 17 */ public boolean moveNext() {
> /* 18 */while (inputEnumerator.moveNext()) {
> /* 19 */ final Object[] current = (Object[]) inputEnumerator.current();
> /* 20 */ final String inp3_ = current[3] == null ? (String) null :
> current[3].toString();
> /* 21 */ if (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.gt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_A_) && (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.lt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_Z_))) {
> /* 22 */return true;
> /* 23 */ }
> /* 24 */}
> /* 25 */return false;
> /* 26 */ }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1059) Not valid to convert Aggregate with on empty to empty if its GROUP BY key is empty
[
https://issues.apache.org/jira/browse/CALCITE-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1059:
-
Fix Version/s: 1.7.0
> Not valid to convert Aggregate with on empty to empty if its GROUP BY key is
> empty
> --
>
> Key: CALCITE-1059
> URL: https://issues.apache.org/jira/browse/CALCITE-1059
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> It it not valid to convert Aggregate with on empty to empty if its GROUP BY
> key is empty. Consider the following SQL:{code}SELECT count(*) FROM emp WHERE
> FALSE{code} Even though the input is empty, the output is one row.
> Fix affects PruneEmptyRules.AGGREGATE_INSTANCE.
> Also, add a RelBuilderFactory argument to all rules in PruneEmptyRules and
> call RelBuilder.empty rather than LogicalValues.createEmpty.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-978) Make ReduceExpressionsRule extensible to transform false filter in schema-on-read case
[ https://issues.apache.org/jira/browse/CALCITE-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-978. - Resolution: Fixed Fix Version/s: 1.6.0 Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/898fdfc2. Thanks for the PR, [~jaltekruse]! > Make ReduceExpressionsRule extensible to transform false filter in > schema-on-read case > --- > > Key: CALCITE-978 > URL: https://issues.apache.org/jira/browse/CALCITE-978 > Project: Calcite > Issue Type: Bug >Reporter: Jinfeng Ni >Assignee: Jason Altekruse > Labels: drill > Fix For: 1.6.0 > > > This comes from a commit in Drill's forked Calcite > (https://github.com/dremio/calcite/commit/a29f007f4f4017368b6f41bf8c3aba4490a1cee8). > ReduceExpressionRule will transform a false filter into VALUES with empty > input. This only works in the case of schema-aware scenario. In > schema-on-read scenario like Drill, VALUES would not provide the schema type > at the planning time; schema has to be propagate during execution time. > We should allow ReduceExpressionRule extensible so that different behavior > would be allowed to handle false filter in both schema-aware case and > schema-on-read case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1056) Simplify predicate of JOIN, and optimize away LIMIT 0
[
https://issues.apache.org/jira/browse/CALCITE-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1056:
-
Fix Version/s: 1.7.0
> Simplify predicate of JOIN, and optimize away LIMIT 0
> -
>
> Key: CALCITE-1056
> URL: https://issues.apache.org/jira/browse/CALCITE-1056
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> Following CALCITE-996, RelBuilder should simplify predicates in other
> situations, such as the {{and}} method and the {{join}} method.
> {{RelBuilder.filter(false)}} and {{RelBuilder.limit(0, 0)}} should simplify
> to {{RelBuilder.empty()}}, a new method that returns an empty relation. The
> default implementation returns a {{Values}} with no rows, but schema-on-query
> systems such as Drill might override the {{empty}} method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1058) Add method RelBuilder.empty, and rewrite LIMIT 0 to it
[ https://issues.apache.org/jira/browse/CALCITE-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1058: - Summary: Add method RelBuilder.empty, and rewrite LIMIT 0 to it (was: Add method RelBuilder.empty, and rewrite LIMIT 0 and WHERE FALSE to it) > Add method RelBuilder.empty, and rewrite LIMIT 0 to it > -- > > Key: CALCITE-1058 > URL: https://issues.apache.org/jira/browse/CALCITE-1058 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > Fix For: 1.6.0 > > > Add a method RelBuilder.empty(), a new method that returns an empty relation. > The default implementation returns a Values with no rows, but schema-on-query > systems such as Drill might override the empty method to read schema from an > input at query time. > RelBuilder.filter(false) and RelBuilder.limit(0, 0) should simplify to > empty(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1045) Decorrelate sub-queries in Project and Join
[ https://issues.apache.org/jira/browse/CALCITE-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15099031#comment-15099031 ] Julian Hyde commented on CALCITE-1045: -- Work in progress at https://github.com/julianhyde/calcite/tree/1045-correlated-project. > Decorrelate sub-queries in Project and Join > --- > > Key: CALCITE-1045 > URL: https://issues.apache.org/jira/browse/CALCITE-1045 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > In CALCITE-816 we created a representation of sub-query in the relational > algebra, RexSubQuery, so that we could defer expanding and de-correlating > sub-queries until after SqlNode tree has been converted to RelNode tree. But > the RelDecorrelator can only reliably handle sub-queries that occur in a > Filter (such as WHERE EXISTS or WHERE IN). > This task would except RelDecorrelator to handle sub-queries in Project > (which occur with scalar sub-queries in the SELECT clause) and sub-queries in > Join (which occur with scalar sub-queries in the ON clause of a JOIN). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1055) SubQueryRemoveRule should create Correlate, not Join, for correlated sub-queries
[
https://issues.apache.org/jira/browse/CALCITE-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1055.
--
Resolution: Fixed
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/cecef9d3.
> SubQueryRemoveRule should create Correlate, not Join, for correlated
> sub-queries
>
>
> Key: CALCITE-1055
> URL: https://issues.apache.org/jira/browse/CALCITE-1055
> Project: Calcite
> Issue Type: Bug
>Reporter: Maryann Xue
>Assignee: Maryann Xue
> Fix For: 1.6.0
>
> Attachments: CALCITE-1055.patch, CALCITE-1055_2.patch
>
>
> In some cases of FILTER correlated subqueries, the "variablesSet" didn't get
> passed down to RelBuilder.join() and thus a Join rel was created while it
> should have been a Correlate rel.
> For example,
> {code}
> select order_id, quantity from orders o
> where quantity = (
> select max(quantity) from orders o2
> where o.item_id = o2.item_id)
> {code}
> Does the same apply to PROJECT and JOIN subqueries, [~julianhyde] ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098643#comment-15098643
]
Kevin Liew commented on CALCITE-1052:
-
Hi Josh. I have found that the docker container will hang when there is less
than about 4GB of RAM or otherwise insufficient resources to start the hadoop
services. I'll email you.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "Two");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> int column1 = rs.getInt("column1");
> if (column1 != 2)
> {
>
[jira] [Updated] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Liew updated CALCITE-1052:
Description:
Create two tables
{code:sql}
DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
KeyColumn VARCHAR(255) PRIMARY KEY,
Column1 VARCHAR(510));
UPSERT INTO SEN.VARCHAR_TABLE VALUES ('One','1');
{code}
{code:sql}
DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
KeyColumn VARCHAR(255) PRIMARY KEY,
Column1 INTEGER);
UPSERT INTO SEN.VARCHAR_TABLE VALUES ('Two',2);
{code}
Running these two programs results in several crashes.
1. select a varchar by parameterized statement resulting in
SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
{code:java}
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.PreparedStatement;
import java.sql.Statement;
public class Hello_World {
public static void main(String[] args) throws SQLException {
try {
Class.forName("org.apache.phoenix.queryserver.client.Driver");
} catch (ClassNotFoundException e) {
System.out.println("Where is your PhoenixDriver");
e.printStackTrace();
return;
}
Connection conn =
DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
conn.setAutoCommit(true);
String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
KeyColumn = ?";
System.out.println("SQL Statement:\n\t" + sqlStmt);
while(true)
{
ResultSet rset = null;
//Statement stmt = conn.createStatement();
PreparedStatement stmt = conn.prepareStatement(sqlStmt);
stmt.setString(1, "One");
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
String column1 = rs.getString("column1");
if (!column1.equals("1"))
{
System.out.println(column1);
}
}
}
//conn.close();
}
}
{code}
2. select an integer by parameterized statement resulting in
SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
{code:java}
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.PreparedStatement;
import java.sql.Statement;
public class Hello_World {
public static void main(String[] args) throws SQLException {
try {
Class.forName("org.apache.phoenix.queryserver.client.Driver");
} catch (ClassNotFoundException e) {
System.out.println("Where is your PhoenixDriver");
e.printStackTrace();
return;
}
Connection conn =
DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
conn.setAutoCommit(true);
String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
KeyColumn = ?";
System.out.println("SQL Statement:\n\t" + sqlStmt);
while(true)
{
ResultSet rset = null;
//Statement stmt = conn.createStatement();
PreparedStatement stmt = conn.prepareStatement(sqlStmt);
stmt.setString(1, "Two");
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
int column1 = rs.getInt("column1");
if (column1 != 2)
{
System.out.println(column1);
}
}
}
//conn.close();
}
}
{code}
There are several crashes (might be preventable by adding a pause in the
loops?), but the one relevant to this bug is:
{code:java}
SQL Statement:
SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = ?
Exception in thread "main" java.lang.ClassCastException: java.lang.String
cannot be cast to java.lang.Number
at
org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:661)
at
org.apache.calcite.avatica.util.AbstractCursor$BigNumberAccessor.getInt(AbstractCursor.java:602)
at
org.apache.calcite.avatica.AvaticaResultSet.getInt(AvaticaResultSet.java:314)
at Hello_World.main(Hello_World.java:36)
{code}
where we get a
[jira] [Updated] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Liew updated CALCITE-1052:
Attachment: phoenix-root-server.log
Attached server log file
{code:java}
2016-01-15 01:10:43,513 WARN org.eclipse.jetty.server.HttpChannel: /
java.lang.RuntimeException: java.sql.SQLException: ERROR 2004 (INT05):
Parameter value unbound :1
at org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:689)
at org.apache.calcite.avatica.jdbc.JdbcMeta.fetch(JdbcMeta.java:774)
at
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:163)
at
org.apache.calcite.avatica.remote.Service$FetchRequest.accept(Service.java:330)
at
org.apache.calcite.avatica.remote.Service$FetchRequest.accept(Service.java:304)
at
org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)
at
org.apache.calcite.avatica.server.AvaticaHandler.handle(AvaticaHandler.java:55)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:497)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.sql.SQLException: ERROR 2004 (INT05): Parameter value unbound :1
at
org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:396)
at
org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:145)
at
org.apache.phoenix.compile.BindManager.getBindValue(BindManager.java:71)
at
org.apache.phoenix.compile.ExpressionCompiler.visit(ExpressionCompiler.java:427)
at
org.apache.phoenix.compile.ExpressionCompiler.visit(ExpressionCompiler.java:141)
at org.apache.phoenix.parse.BindParseNode.accept(BindParseNode.java:47)
at
org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
at
org.apache.phoenix.parse.ComparisonParseNode.accept(ComparisonParseNode.java:45)
at
org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:130)
at
org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:100)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:537)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:490)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:201)
at
org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:158)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:383)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:357)
at
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:263)
at
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:258)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:257)
at
org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:245)
at
org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:172)
at
org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:177)
at org.apache.calcite.avatica.jdbc.JdbcMeta.fetch(JdbcMeta.java:763)
... 14 more
{code}
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: phoenix-root-server.log, test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ('One','1');
[jira] [Updated] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Liew updated CALCITE-1052:
Description:
Create two tables
{code:sql}
DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
KeyColumn VARCHAR(255) PRIMARY KEY,
Column1 VARCHAR(510));
UPSERT INTO SEN.VARCHAR_TABLE VALUES ('One','1');
{code}
{code:sql}
DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
KeyColumn VARCHAR(255) PRIMARY KEY,
Column1 INTEGER);
UPSERT INTO SEN.INTEGER_TABLE VALUES ('Two',2);
{code}
Running these two programs results in several crashes.
1. select a varchar by parameterized statement resulting in
SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
{code:java}
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.PreparedStatement;
import java.sql.Statement;
public class Hello_World {
public static void main(String[] args) throws SQLException {
try {
Class.forName("org.apache.phoenix.queryserver.client.Driver");
} catch (ClassNotFoundException e) {
System.out.println("Where is your PhoenixDriver");
e.printStackTrace();
return;
}
Connection conn =
DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
conn.setAutoCommit(true);
String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
KeyColumn = ?";
System.out.println("SQL Statement:\n\t" + sqlStmt);
while(true)
{
ResultSet rset = null;
//Statement stmt = conn.createStatement();
PreparedStatement stmt = conn.prepareStatement(sqlStmt);
stmt.setString(1, "One");
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
String column1 = rs.getString("column1");
if (!column1.equals("1"))
{
System.out.println(column1);
}
}
}
//conn.close();
}
}
{code}
2. select an integer by parameterized statement resulting in
SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
{code:java}
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.PreparedStatement;
import java.sql.Statement;
public class Hello_World {
public static void main(String[] args) throws SQLException {
try {
Class.forName("org.apache.phoenix.queryserver.client.Driver");
} catch (ClassNotFoundException e) {
System.out.println("Where is your PhoenixDriver");
e.printStackTrace();
return;
}
Connection conn =
DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
conn.setAutoCommit(true);
String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
KeyColumn = ?";
System.out.println("SQL Statement:\n\t" + sqlStmt);
while(true)
{
ResultSet rset = null;
//Statement stmt = conn.createStatement();
PreparedStatement stmt = conn.prepareStatement(sqlStmt);
stmt.setString(1, "Two");
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
int column1 = rs.getInt("column1");
if (column1 != 2)
{
System.out.println(column1);
}
}
}
//conn.close();
}
}
{code}
There are several crashes (might be preventable by adding a pause in the
loops?), but the one relevant to this bug is:
{code:java}
SQL Statement:
SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = ?
Exception in thread "main" java.lang.ClassCastException: java.lang.String
cannot be cast to java.lang.Number
at
org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:661)
at
org.apache.calcite.avatica.util.AbstractCursor$BigNumberAccessor.getInt(AbstractCursor.java:602)
at
org.apache.calcite.avatica.AvaticaResultSet.getInt(AvaticaResultSet.java:314)
at Hello_World.main(Hello_World.java:36)
{code}
where we get a
[jira] [Resolved] (CALCITE-1058) Add method RelBuilder.empty, and rewrite LIMIT 0 to it
[ https://issues.apache.org/jira/browse/CALCITE-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-1058. -- Resolution: Fixed Fix Version/s: 1.6.0 Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/ee283cad. > Add method RelBuilder.empty, and rewrite LIMIT 0 to it > -- > > Key: CALCITE-1058 > URL: https://issues.apache.org/jira/browse/CALCITE-1058 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > Fix For: 1.6.0 > > > Add a method RelBuilder.empty(), a new method that returns an empty relation. > The default implementation returns a Values with no rows, but schema-on-query > systems such as Drill might override the empty method to read schema from an > input at query time. > RelBuilder.filter(false) and RelBuilder.limit(0, 0) should simplify to > empty(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1059) Not valid to convert Aggregate with on empty to empty if its GROUP BY key is empty
Julian Hyde created CALCITE-1059:
Summary: Not valid to convert Aggregate with on empty to empty if
its GROUP BY key is empty
Key: CALCITE-1059
URL: https://issues.apache.org/jira/browse/CALCITE-1059
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
It it not valid to convert Aggregate with on empty to empty if its GROUP BY key
is empty. Consider the following SQL:{code}SELECT count(*) FROM emp WHERE
FALSE{code} Even though the input is empty, the output is one row.
Fix affects PruneEmptyRules.AGGREGATE_INSTANCE.
Also, add a RelBuilderFactory argument to all rules in PruneEmptyRules and call
RelBuilder.empty rather than LogicalValues.createEmpty.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1054) NPE caused by wrong code generation for Timestamp fields
[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098894#comment-15098894
]
Frankie Bollaert edited comment on CALCITE-1054 at 1/14/16 9:27 PM:
How do you execute these .iq files?
Is it by copy/pasting the statements in a terminal?
was (Author: frankieb):
How do you execute these .iq files?
Is it by copy/pasting the statements in a terminal?
> NPE caused by wrong code generation for Timestamp fields
>
>
> Key: CALCITE-1054
> URL: https://issues.apache.org/jira/browse/CALCITE-1054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.0-incubating, 1.5.0
>Reporter: Frankie Bollaert
>Assignee: Julian Hyde
>Priority: Minor
>
> Problem occurs when:
> - Execute a query containing 2 checks on a Timestamp field
> - Table contains records which have NULL values for this field
> Example query:
> {code}
> select * from aTable where aTimestamp > timestamp '2015-1-1 00:00:00' and
> aTimestamp < timestamp '2015-2-1 00:00:00';
> {code}
> {code}
> /* 48 */ public boolean moveNext() {
> /* 49 */ while (inputEnumerator.moveNext()) {
> /* 50 */ final java.sql.Timestamp inp23_ = (java.sql.Timestamp)
> ((Object[]) inputEnumerator.current())[23];
> /* 51 */ final long v =
> org.apache.calcite.runtime.SqlFunctions.toLong(inp23_);
> /* 52 */ if (inp23_ != null && v > 142007040L && (inp23_ != null
> && v < 142274880L)) {
> /* 53 */ return true;
> /* 54 */ }
> /* 55 */ }
> /* 56 */ return false;
> /* 57 */ }
> {code}
> Stack trace snippet
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1094)
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1089)
> at Baz$1$1.moveNext(ANONYMOUS.java:51)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:677)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:103)
> {code}
> The generated code also looks wrong for date fields.
> {code}
> /* 15 */ public boolean moveNext() {
> /* 16 */ while (inputEnumerator.moveNext()) {
> /* 17 */ final java.sql.Date current = (java.sql.Date)
> inputEnumerator.current();
> /* 18 */ final int v =
> org.apache.calcite.runtime.SqlFunctions.toInt(current);
> /* 19 */ if (current != null && v > 2780 && (current != null && v <
> 5290)) {
> /* 20 */ return true;
> /* 21 */ }
> /* 22 */ }
> /* 23 */ return false;
> /* 24 */ }
> {code}
> \\
> Other types of fields do not have this problem. Below is what the generated
> code looks like in the case of a String field. *On line 20 there is a null
> check.* This is the type of check that needs to be generated for Timestamp
> fields as well.
> {code}
> select empno from sales.emps where gender > 'A' and gender < 'Z';
> {code}
> {code}
> /* 17 */ public boolean moveNext() {
> /* 18 */while (inputEnumerator.moveNext()) {
> /* 19 */ final Object[] current = (Object[]) inputEnumerator.current();
> /* 20 */ final String inp3_ = current[3] == null ? (String) null :
> current[3].toString();
> /* 21 */ if (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.gt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_A_) && (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.lt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_Z_))) {
> /* 22 */return true;
> /* 23 */ }
> /* 24 */}
> /* 25 */return false;
> /* 26 */ }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1055) SqlToRelConverter should create Correlate, not Join, for correlated sub-queries
[
https://issues.apache.org/jira/browse/CALCITE-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1055:
-
Summary: SqlToRelConverter should create Correlate, not Join, for
correlated sub-queries (was: Correlate rel instead of Join rel should be
created for correlated subqueries before decorrelation)
> SqlToRelConverter should create Correlate, not Join, for correlated
> sub-queries
> ---
>
> Key: CALCITE-1055
> URL: https://issues.apache.org/jira/browse/CALCITE-1055
> Project: Calcite
> Issue Type: Bug
>Reporter: Maryann Xue
>Assignee: Maryann Xue
> Fix For: 1.6.0
>
> Attachments: CALCITE-1055.patch, CALCITE-1055_2.patch
>
>
> In some cases of FILTER correlated subqueries, the "variablesSet" didn't get
> passed down to RelBuilder.join() and thus a Join rel was created while it
> should have been a Correlate rel.
> For example,
> {code}
> select order_id, quantity from orders o
> where quantity = (
> select max(quantity) from orders o2
> where o.item_id = o2.item_id)
> {code}
> Does the same apply to PROJECT and JOIN subqueries, [~julianhyde] ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1056) Simplify predicate of JOIN, and optimize away LIMIT 0
[
https://issues.apache.org/jira/browse/CALCITE-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098852#comment-15098852
]
Julian Hyde commented on CALCITE-1056:
--
Work in progress: https://github.com/julianhyde/calcite/tree/1056-simplify.
CALCITE-1054 is similar, lower ambition level, and should make it into release
1.6. This case will have to wait until 1.7.
> Simplify predicate of JOIN, and optimize away LIMIT 0
> -
>
> Key: CALCITE-1056
> URL: https://issues.apache.org/jira/browse/CALCITE-1056
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Following CALCITE-996, RelBuilder should simplify predicates in other
> situations, such as the {{and}} method and the {{join}} method.
> {{RelBuilder.filter(false)}} and {{RelBuilder.limit(0, 0)}} should simplify
> to {{RelBuilder.empty()}}, a new method that returns an empty relation. The
> default implementation returns a {{Values}} with no rows, but schema-on-query
> systems such as Drill might override the {{empty}} method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1054) NPE caused by wrong code generation for Timestamp fields
[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098772#comment-15098772
]
Julian Hyde commented on CALCITE-1054:
--
Unfortunately it still seems to be an issue on master. See
https://github.com/julianhyde/calcite/tree/1054-timestamp-npe, a branch
containing a test case.
> NPE caused by wrong code generation for Timestamp fields
>
>
> Key: CALCITE-1054
> URL: https://issues.apache.org/jira/browse/CALCITE-1054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.0-incubating, 1.5.0
>Reporter: Frankie Bollaert
>Assignee: Julian Hyde
>Priority: Minor
>
> Problem occurs when:
> - Execute a query containing 2 checks on a Timestamp field
> - Table contains records which have NULL values for this field
> Example query:
> {code}
> select * from aTable where aTimestamp > timestamp '2015-1-1 00:00:00' and
> aTimestamp < timestamp '2015-2-1 00:00:00';
> {code}
> {code}
> /* 48 */ public boolean moveNext() {
> /* 49 */ while (inputEnumerator.moveNext()) {
> /* 50 */ final java.sql.Timestamp inp23_ = (java.sql.Timestamp)
> ((Object[]) inputEnumerator.current())[23];
> /* 51 */ final long v =
> org.apache.calcite.runtime.SqlFunctions.toLong(inp23_);
> /* 52 */ if (inp23_ != null && v > 142007040L && (inp23_ != null
> && v < 142274880L)) {
> /* 53 */ return true;
> /* 54 */ }
> /* 55 */ }
> /* 56 */ return false;
> /* 57 */ }
> {code}
> Stack trace snippet
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1094)
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1089)
> at Baz$1$1.moveNext(ANONYMOUS.java:51)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:677)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:103)
> {code}
> The generated code also looks wrong for date fields.
> {code}
> /* 15 */ public boolean moveNext() {
> /* 16 */ while (inputEnumerator.moveNext()) {
> /* 17 */ final java.sql.Date current = (java.sql.Date)
> inputEnumerator.current();
> /* 18 */ final int v =
> org.apache.calcite.runtime.SqlFunctions.toInt(current);
> /* 19 */ if (current != null && v > 2780 && (current != null && v <
> 5290)) {
> /* 20 */ return true;
> /* 21 */ }
> /* 22 */ }
> /* 23 */ return false;
> /* 24 */ }
> {code}
> \\
> Other types of fields do not have this problem. Below is what the generated
> code looks like in the case of a String field. *On line 20 there is a null
> check.* This is the type of check that needs to be generated for Timestamp
> fields as well.
> {code}
> select empno from sales.emps where gender > 'A' and gender < 'Z';
> {code}
> {code}
> /* 17 */ public boolean moveNext() {
> /* 18 */while (inputEnumerator.moveNext()) {
> /* 19 */ final Object[] current = (Object[]) inputEnumerator.current();
> /* 20 */ final String inp3_ = current[3] == null ? (String) null :
> current[3].toString();
> /* 21 */ if (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.gt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_A_) && (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.lt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_Z_))) {
> /* 22 */return true;
> /* 23 */ }
> /* 24 */}
> /* 25 */return false;
> /* 26 */ }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1052) Phoenix queryserver sends result set in response to the wrong request when there are concurrent requests
[
https://issues.apache.org/jira/browse/CALCITE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098643#comment-15098643
]
Kevin Liew edited comment on CALCITE-1052 at 1/14/16 7:11 PM:
--
Hi Josh. I have found that the docker container will hang when there is less
than about 4GB of RAM (on a dedicated VM) or otherwise insufficient resources
to start the hadoop services. I'll email you.
was (Author: kliew):
Hi Josh. I have found that the docker container will hang when there is less
than about 4GB of RAM or otherwise insufficient resources to start the hadoop
services. I'll email you.
> Phoenix queryserver sends result set in response to the wrong request when
> there are concurrent requests
>
>
> Key: CALCITE-1052
> URL: https://issues.apache.org/jira/browse/CALCITE-1052
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Kevin Liew
>Assignee: Josh Elser
>Priority: Critical
> Labels: phoenix, queryserver
> Attachments: test.zip
>
>
> Create two tables
> {code:sql}
> DROP TABLE IF EXISTS SEN.VARCHAR_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.VARCHAR_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 VARCHAR(510));
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("One","1");
> {code}
> {code:sql}
> DROP TABLE IF EXISTS SEN.INTEGER_TABLE;
> CREATE TABLE IF NOT EXISTS SEN.INTEGER_TABLE(
> KeyColumn VARCHAR(255) PRIMARY KEY,
> Column1 INTEGER);
> UPSERT INTO SEN.VARCHAR_TABLE VALUES ("Two",2);
> {code}
> Running these two programs results in several crashes.
> 1. select a varchar by parameterized statement resulting in
> SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE KeyColumn = 'One'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
> String sqlStmt = "SELECT Column1 FROM SEN.VARCHAR_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
> stmt.setString(1, "One");
> ResultSet rs = stmt.executeQuery();
>
> while (rs.next()) {
> String column1 = rs.getString("column1");
> if (!column1.equals("1"))
> {
> System.out.println(column1);
> }
> }
> }
>
> //conn.close();
> }
>
> }
> {code}
> 2. select an integer by parameterized statement resulting in
> SELECT Column1 FROM SEN.INTEGER_TABLE WHERE KeyColumn = 'Two'
> {code:java}
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.PreparedStatement;
> import java.sql.Statement;
> public class Hello_World {
> public static void main(String[] args) throws SQLException {
> try {
> Class.forName("org.apache.phoenix.queryserver.client.Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("Where is your PhoenixDriver");
> e.printStackTrace();
> return;
> }
> Connection conn =
> DriverManager.getConnection("jdbc:phoenix:thin:url=http://192.168.222.52:8765;);
> conn.setAutoCommit(true);
>
> String sqlStmt = "SELECT Column1 FROM SEN.INTEGER_TABLE WHERE
> KeyColumn = ?";
> System.out.println("SQL Statement:\n\t" + sqlStmt);
>
> while(true)
> {
> ResultSet rset = null;
>
> //Statement stmt = conn.createStatement();
> PreparedStatement stmt = conn.prepareStatement(sqlStmt);
>
[jira] [Updated] (CALCITE-1054) NPE caused by wrong code generation for Timestamp fields
[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frankie Bollaert updated CALCITE-1054:
--
Affects Version/s: 1.5.0
> NPE caused by wrong code generation for Timestamp fields
>
>
> Key: CALCITE-1054
> URL: https://issues.apache.org/jira/browse/CALCITE-1054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.0-incubating, 1.5.0
>Reporter: Frankie Bollaert
>Assignee: Julian Hyde
>Priority: Minor
>
> Problem occurs when:
> - Execute a query containing 2 checks on a Timestamp field
> - Table contains records which have NULL values for this field
> Example query:
> {code}
> select * from aTable where aTimestamp > timestamp '2015-1-1 00:00:00' and
> aTimestamp < timestamp '2015-2-1 00:00:00';
> {code}
> {code}
> /* 48 */ public boolean moveNext() {
> /* 49 */ while (inputEnumerator.moveNext()) {
> /* 50 */ final java.sql.Timestamp inp23_ = (java.sql.Timestamp)
> ((Object[]) inputEnumerator.current())[23];
> /* 51 */ final long v =
> org.apache.calcite.runtime.SqlFunctions.toLong(inp23_);
> /* 52 */ if (inp23_ != null && v > 142007040L && (inp23_ != null
> && v < 142274880L)) {
> /* 53 */ return true;
> /* 54 */ }
> /* 55 */ }
> /* 56 */ return false;
> /* 57 */ }
> {code}
> Stack trace snippet
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1094)
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1089)
> at Baz$1$1.moveNext(ANONYMOUS.java:51)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:677)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:103)
> {code}
> The generated code also looks wrong for date fields.
> {code}
> /* 15 */ public boolean moveNext() {
> /* 16 */ while (inputEnumerator.moveNext()) {
> /* 17 */ final java.sql.Date current = (java.sql.Date)
> inputEnumerator.current();
> /* 18 */ final int v =
> org.apache.calcite.runtime.SqlFunctions.toInt(current);
> /* 19 */ if (current != null && v > 2780 && (current != null && v <
> 5290)) {
> /* 20 */ return true;
> /* 21 */ }
> /* 22 */ }
> /* 23 */ return false;
> /* 24 */ }
> {code}
> \\
> Other types of fields do not have this problem. Below is what the generated
> code looks like in the case of a String field. *On line 20 there is a null
> check.* This is the type of check that needs to be generated for Timestamp
> fields as well.
> {code}
> select empno from sales.emps where gender > 'A' and gender < 'Z';
> {code}
> {code}
> /* 17 */ public boolean moveNext() {
> /* 18 */while (inputEnumerator.moveNext()) {
> /* 19 */ final Object[] current = (Object[]) inputEnumerator.current();
> /* 20 */ final String inp3_ = current[3] == null ? (String) null :
> current[3].toString();
> /* 21 */ if (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.gt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_A_) && (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.lt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_Z_))) {
> /* 22 */return true;
> /* 23 */ }
> /* 24 */}
> /* 25 */return false;
> /* 26 */ }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1054) NPE caused by wrong code generation for Timestamp fields
[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098136#comment-15098136
]
Frankie Bollaert edited comment on CALCITE-1054 at 1/14/16 2:40 PM:
Thank you Julian, your pointers are very helpful.
The snippets of generated code in this issue where created using Calcite 1.4.
Using the code of the git master branch produces a different result. If you
are not planning any 1.4 or 1.5 (which generates similar code) branch releases,
then this issue is not relevant, and may best be closed.
was (Author: frankieb):
Thank you Julian, your pointers are very helpful.
The snippets of generated code in this issue where created using Calcite 1.4.
Using the code of the git master branch produces a different result. If you
are not planning any 1.4 branch releases, then this issue is not relevant, and
may best be closed.
> NPE caused by wrong code generation for Timestamp fields
>
>
> Key: CALCITE-1054
> URL: https://issues.apache.org/jira/browse/CALCITE-1054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.0-incubating
>Reporter: Frankie Bollaert
>Assignee: Julian Hyde
>Priority: Minor
>
> Problem occurs when:
> - Execute a query containing 2 checks on a Timestamp field
> - Table contains records which have NULL values for this field
> Example query:
> {code}
> select * from aTable where aTimestamp > timestamp '2015-1-1 00:00:00' and
> aTimestamp < timestamp '2015-2-1 00:00:00';
> {code}
> {code}
> /* 48 */ public boolean moveNext() {
> /* 49 */ while (inputEnumerator.moveNext()) {
> /* 50 */ final java.sql.Timestamp inp23_ = (java.sql.Timestamp)
> ((Object[]) inputEnumerator.current())[23];
> /* 51 */ final long v =
> org.apache.calcite.runtime.SqlFunctions.toLong(inp23_);
> /* 52 */ if (inp23_ != null && v > 142007040L && (inp23_ != null
> && v < 142274880L)) {
> /* 53 */ return true;
> /* 54 */ }
> /* 55 */ }
> /* 56 */ return false;
> /* 57 */ }
> {code}
> Stack trace snippet
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1094)
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1089)
> at Baz$1$1.moveNext(ANONYMOUS.java:51)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:677)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:103)
> {code}
> The generated code also looks wrong for date fields.
> {code}
> /* 15 */ public boolean moveNext() {
> /* 16 */ while (inputEnumerator.moveNext()) {
> /* 17 */ final java.sql.Date current = (java.sql.Date)
> inputEnumerator.current();
> /* 18 */ final int v =
> org.apache.calcite.runtime.SqlFunctions.toInt(current);
> /* 19 */ if (current != null && v > 2780 && (current != null && v <
> 5290)) {
> /* 20 */ return true;
> /* 21 */ }
> /* 22 */ }
> /* 23 */ return false;
> /* 24 */ }
> {code}
> \\
> Other types of fields do not have this problem. Below is what the generated
> code looks like in the case of a String field. *On line 20 there is a null
> check.* This is the type of check that needs to be generated for Timestamp
> fields as well.
> {code}
> select empno from sales.emps where gender > 'A' and gender < 'Z';
> {code}
> {code}
> /* 17 */ public boolean moveNext() {
> /* 18 */while (inputEnumerator.moveNext()) {
> /* 19 */ final Object[] current = (Object[]) inputEnumerator.current();
> /* 20 */ final String inp3_ = current[3] == null ? (String) null :
> current[3].toString();
> /* 21 */ if (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.gt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_A_) && (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.lt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_Z_))) {
> /* 22 */return true;
> /* 23 */ }
> /* 24 */}
> /* 25 */return false;
> /* 26 */ }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1054) NPE caused by wrong code generation for Timestamp fields
[
https://issues.apache.org/jira/browse/CALCITE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098955#comment-15098955
]
Julian Hyde commented on CALCITE-1054:
--
See e.g. JdbcTest.testRunMisc.
> NPE caused by wrong code generation for Timestamp fields
>
>
> Key: CALCITE-1054
> URL: https://issues.apache.org/jira/browse/CALCITE-1054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.0-incubating, 1.5.0
>Reporter: Frankie Bollaert
>Assignee: Julian Hyde
>Priority: Minor
>
> Problem occurs when:
> - Execute a query containing 2 checks on a Timestamp field
> - Table contains records which have NULL values for this field
> Example query:
> {code}
> select * from aTable where aTimestamp > timestamp '2015-1-1 00:00:00' and
> aTimestamp < timestamp '2015-2-1 00:00:00';
> {code}
> {code}
> /* 48 */ public boolean moveNext() {
> /* 49 */ while (inputEnumerator.moveNext()) {
> /* 50 */ final java.sql.Timestamp inp23_ = (java.sql.Timestamp)
> ((Object[]) inputEnumerator.current())[23];
> /* 51 */ final long v =
> org.apache.calcite.runtime.SqlFunctions.toLong(inp23_);
> /* 52 */ if (inp23_ != null && v > 142007040L && (inp23_ != null
> && v < 142274880L)) {
> /* 53 */ return true;
> /* 54 */ }
> /* 55 */ }
> /* 56 */ return false;
> /* 57 */ }
> {code}
> Stack trace snippet
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1094)
> at
> org.apache.calcite.runtime.SqlFunctions.toLong(SqlFunctions.java:1089)
> at Baz$1$1.moveNext(ANONYMOUS.java:51)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:677)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:103)
> {code}
> The generated code also looks wrong for date fields.
> {code}
> /* 15 */ public boolean moveNext() {
> /* 16 */ while (inputEnumerator.moveNext()) {
> /* 17 */ final java.sql.Date current = (java.sql.Date)
> inputEnumerator.current();
> /* 18 */ final int v =
> org.apache.calcite.runtime.SqlFunctions.toInt(current);
> /* 19 */ if (current != null && v > 2780 && (current != null && v <
> 5290)) {
> /* 20 */ return true;
> /* 21 */ }
> /* 22 */ }
> /* 23 */ return false;
> /* 24 */ }
> {code}
> \\
> Other types of fields do not have this problem. Below is what the generated
> code looks like in the case of a String field. *On line 20 there is a null
> check.* This is the type of check that needs to be generated for Timestamp
> fields as well.
> {code}
> select empno from sales.emps where gender > 'A' and gender < 'Z';
> {code}
> {code}
> /* 17 */ public boolean moveNext() {
> /* 18 */while (inputEnumerator.moveNext()) {
> /* 19 */ final Object[] current = (Object[]) inputEnumerator.current();
> /* 20 */ final String inp3_ = current[3] == null ? (String) null :
> current[3].toString();
> /* 21 */ if (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.gt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_A_) && (inp3_ != null &&
> org.apache.calcite.runtime.SqlFunctions.lt(inp3_,
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_rtrim_Z_))) {
> /* 22 */return true;
> /* 23 */ }
> /* 24 */}
> /* 25 */return false;
> /* 26 */ }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
