[jira] [Commented] (CALCITE-508) Reading from ResultSet before calling next() should throw SQLException not NoSuchElementException
[
https://issues.apache.org/jira/browse/CALCITE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346311#comment-16346311
]
ASF GitHub Bot commented on CALCITE-508:
Github user vlsi commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/23#discussion_r164959898
--- Diff:
core/src/test/java/org/apache/calcite/avatica/AvaticaResultSetThrowsSqlExceptionTest.java
---
@@ -75,11 +90,118 @@ public void testUpdateNull() throws SQLException {
final TestDriver driver = new TestDriver();
try (Connection connection = driver.connect("jdbc:test", properties);
ResultSet resultSet =
- connection.createStatement().executeQuery("SELECT * FROM
TABLE")) {
+ connection.createStatement().executeQuery("SELECT * FROM
TABLE")) {
thrown.expect(SQLFeatureNotSupportedException.class);
resultSet.updateNull(1);
}
}
-}
+ @Test
+ public void testCommonCursorStates() throws SQLException {
+final ResultSet resultSet = getResultSet();
+
+// right after statement execution, result set is before first row
+assert resultSet.isBeforeFirst();
+
+// retrieve each row until the last one
+while (!resultSet.isAfterLast()) {
+ assert resultSet.next() != resultSet.isAfterLast();
--- End diff --
Please avoid using Java asserts in the test code. Test failures will be
hard to understand/analyze in case of assert failures.
> Reading from ResultSet before calling next() should throw SQLException not
> NoSuchElementException
> -
>
> Key: CALCITE-508
> URL: https://issues.apache.org/jira/browse/CALCITE-508
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Reading from ResultSet before calling next() should throw SQLException not
> NoSuchElementException.
> Each of the Cursor.Accessor.getXxx methods should convert runtime exceptions
> to SQLException.
> JdbcTest.testExtract currently demonstrates this problem; it passes if there
> is a NoSuchElementException, but should look for a SQLException.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-508) Reading from ResultSet before calling next() should throw SQLException not NoSuchElementException
[
https://issues.apache.org/jira/browse/CALCITE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346314#comment-16346314
]
ASF GitHub Bot commented on CALCITE-508:
Github user vlsi commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/23#discussion_r164960143
--- Diff:
core/src/test/java/org/apache/calcite/avatica/AvaticaResultSetThrowsSqlExceptionTest.java
---
@@ -75,11 +90,118 @@ public void testUpdateNull() throws SQLException {
final TestDriver driver = new TestDriver();
try (Connection connection = driver.connect("jdbc:test", properties);
ResultSet resultSet =
- connection.createStatement().executeQuery("SELECT * FROM
TABLE")) {
+ connection.createStatement().executeQuery("SELECT * FROM
TABLE")) {
thrown.expect(SQLFeatureNotSupportedException.class);
resultSet.updateNull(1);
}
}
-}
+ @Test
+ public void testCommonCursorStates() throws SQLException {
+final ResultSet resultSet = getResultSet();
+
+// right after statement execution, result set is before first row
+assert resultSet.isBeforeFirst();
+
+// retrieve each row until the last one
+while (!resultSet.isAfterLast()) {
+ assert resultSet.next() != resultSet.isAfterLast();
+}
+
+// result set is not closed yet, despite fully consumed
+assert !resultSet.isClosed();
+
+resultSet.close();
+
+// result set is now closed
+assert resultSet.isClosed();
+
+// once closed, next should fail
+thrown.expect(SQLException.class);
+resultSet.next();
+ }
+
+ /**
+ * Auxiliary method for testing column access.
+ * @param resultSet the result set
+ * @param index the index of the column to be accessed
+ * @param shouldThrow true iff the column access should throw an
exception
+ * @return true iff the method invocation succeeded
+ * @throws SQLException in case of database error
+ */
+ private boolean getColumn(final ResultSet resultSet,
+final int index,
+final boolean shouldThrow) throws SQLException
{
+try {
+ switch (index) {
+ case 1:
+resultSet.getBoolean(index); // BOOLEAN
+break;
+ case 2:
+resultSet.getByte(index); // TINYINT
+break;
+ case 3:
+resultSet.getShort(index); // SMALLINT
+break;
+ case 4:
+resultSet.getInt(index); // INTEGER
+break;
+ case 5:
+resultSet.getLong(index); // BIGINT
+break;
+ case 6:
+resultSet.getFloat(index); // REAL
+break;
+ case 7:
+resultSet.getDouble(index);// FLOAT
+break;
+ case 8:
+resultSet.getString(index);// VARCHAR
+break;
+ case 9:
+resultSet.getDate(index); // DATE
+break;
+ case 10:
+resultSet.getTime(index); // TIME
+break;
+ case 11:
+resultSet.getTimestamp(index); // TIMESTAMP
+break;
+ default:
+resultSet.getObject(index);
+ }
+} catch (SQLException e) {
+ if (!shouldThrow) {
+throw e;
+ }
+ return true;
+}
+
+return !shouldThrow;
+ }
+
+ @Test
+ public void testGetColumnsBeforeNext() throws SQLException {
+try (ResultSet resultSet = getResultSet()) {
+ // we have not called next, so each column getter should throw
SQLException
+ for (int i = 1; i <= resultSet.getMetaData().getColumnCount(); i++) {
+//System.out.println(resultSet.getMetaData().getColumnTypeName(i));
+assert getColumn(resultSet, i, true);
+ }
+}
+ }
+
+ @Test
+ public void testGetColumnsAfterNext() throws SQLException {
--- End diff --
Is there `getColumnsAfterLast` test?
> Reading from ResultSet before calling next() should throw SQLException not
> NoSuchElementException
> -
>
> Key: CALCITE-508
> URL: https://issues.apache.org/jira/browse/CALCITE-508
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Reading from ResultSet before calling next() should throw SQLException not
> NoSuchElementException.
> Each of the
[jira] [Commented] (CALCITE-508) Reading from ResultSet before calling next() should throw SQLException not NoSuchElementException
[
https://issues.apache.org/jira/browse/CALCITE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346313#comment-16346313
]
ASF GitHub Bot commented on CALCITE-508:
Github user vlsi commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/23#discussion_r164958640
--- Diff:
core/src/main/java/org/apache/calcite/avatica/util/IteratorCursor.java ---
@@ -68,7 +68,7 @@ public void close() {
protected E current() {
if (position != Position.OK) {
- throw new NoSuchElementException();
+ throw new NoSuchElementException("Invalid cursor position");
--- End diff --
Please add actual position to the exception message.
Consider what would engineer do with `Invalid cursor position`. Why is the
position invalid?
I would be much better if error message was `Expecting cursor position to
be Position.OK, actual is ...`
> Reading from ResultSet before calling next() should throw SQLException not
> NoSuchElementException
> -
>
> Key: CALCITE-508
> URL: https://issues.apache.org/jira/browse/CALCITE-508
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Reading from ResultSet before calling next() should throw SQLException not
> NoSuchElementException.
> Each of the Cursor.Accessor.getXxx methods should convert runtime exceptions
> to SQLException.
> JdbcTest.testExtract currently demonstrates this problem; it passes if there
> is a NoSuchElementException, but should look for a SQLException.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-508) Reading from ResultSet before calling next() should throw SQLException not NoSuchElementException
[
https://issues.apache.org/jira/browse/CALCITE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346312#comment-16346312
]
ASF GitHub Bot commented on CALCITE-508:
Github user vlsi commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/23#discussion_r164959963
--- Diff:
core/src/test/java/org/apache/calcite/avatica/AvaticaResultSetThrowsSqlExceptionTest.java
---
@@ -75,11 +90,118 @@ public void testUpdateNull() throws SQLException {
final TestDriver driver = new TestDriver();
try (Connection connection = driver.connect("jdbc:test", properties);
ResultSet resultSet =
- connection.createStatement().executeQuery("SELECT * FROM
TABLE")) {
+ connection.createStatement().executeQuery("SELECT * FROM
TABLE")) {
thrown.expect(SQLFeatureNotSupportedException.class);
resultSet.updateNull(1);
}
}
-}
+ @Test
+ public void testCommonCursorStates() throws SQLException {
+final ResultSet resultSet = getResultSet();
+
+// right after statement execution, result set is before first row
+assert resultSet.isBeforeFirst();
+
+// retrieve each row until the last one
+while (!resultSet.isAfterLast()) {
--- End diff --
Infinite loop is possible. Please add a counter
> Reading from ResultSet before calling next() should throw SQLException not
> NoSuchElementException
> -
>
> Key: CALCITE-508
> URL: https://issues.apache.org/jira/browse/CALCITE-508
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Reading from ResultSet before calling next() should throw SQLException not
> NoSuchElementException.
> Each of the Cursor.Accessor.getXxx methods should convert runtime exceptions
> to SQLException.
> JdbcTest.testExtract currently demonstrates this problem; it passes if there
> is a NoSuchElementException, but should look for a SQLException.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2059) Apache Geode adapter
[ https://issues.apache.org/jira/browse/CALCITE-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346269#comment-16346269 ] Julian Hyde commented on CALCITE-2059: -- [~michaelmior] tells me that he is reviewing this but is waiting for a response from [~tzolov]. > Apache Geode adapter > > > Key: CALCITE-2059 > URL: https://issues.apache.org/jira/browse/CALCITE-2059 > Project: Calcite > Issue Type: New Feature >Reporter: Christian Tzolov >Assignee: Julian Hyde >Priority: Major > > I've been working on a Calcite adapter for [Apache > Geode|http://geode.apache.org]. > Current implementation uses the plain Geode API and > [OQL|http://geode.apache.org/docs/guide/13/developing/querying_basics/chapter_overview.html](Object > Query Interface) to push down relational expressions such as projections, > filtering, sorting, and grouping . > Provided functionality can hopefully address certain Geode use cases and will > provide a stepping stone for future improvements. > Here are some remaining tasks as i see it: > * New tests for test suite (and update calcite-test-dataset to support Geode) > * Add Integration tests that use calcite-test-dataset > * Documentation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2159) UNNEST to support 'ANY' type
[ https://issues.apache.org/jira/browse/CALCITE-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346267#comment-16346267 ] Julian Hyde commented on CALCITE-2159: -- It sounds as if ANY is a poor fit for what you need. You need a record (struct) type that you can write fields into, and ANY is neither of those. Are there any unit tests in Calcite for how Drill infers types based on usage? A good place to start might be to add test cases to those unit tests. > UNNEST to support 'ANY' type > > > Key: CALCITE-2159 > URL: https://issues.apache.org/jira/browse/CALCITE-2159 > Project: Calcite > Issue Type: Bug >Reporter: Chunhui Shi >Assignee: Julian Hyde >Priority: Major > > Not all data source has type information about the input of UNNEST during > parsing stage. In Drill, if we want to support UNNEST(table.column) syntax > for a document with nested structure, for now, these two things will happen: > SqlUnnestOperator.inferReturnType will use unknown operand's type 'ANY' so > isStruct will be false, thus the the following code will hit NULL reference. > > Another issue is, Should UnnestnameSpace.getTable return a table so when > other parts of the query tried to refer to some columns coming out of UNNEST, > we know the query is asking for a column from the table, so the parser could > add the column to the RowType of UNNEST? An example query is like this: > SELECT AVG(o.o_amount) AS avg_orders FROM UNNEST(c.orders) AS o > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2161) Add "types" collection to the schema element in the JSON model
[
https://issues.apache.org/jira/browse/CALCITE-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346265#comment-16346265
]
Julian Hyde commented on CALCITE-2161:
--
Can you change {{getType}} to return {{RelProtoDataType}}? A type belongs to a
type-factory, and schemas live longer than type-factories, therefore they
cannot contain types. Also, you'll need a method in {{AbstractSchema}} that is
analogous to {{getTableMap()}}.
> Add "types" collection to the schema element in the JSON model
> --
>
> Key: CALCITE-2161
> URL: https://issues.apache.org/jira/browse/CALCITE-2161
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.16.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
> As discussed in CALCITE-2045, we need to add "types" collection in the schema
> element in the JSON model.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2161) Add "types" collection to the schema element in the JSON model
Shuyi Chen created CALCITE-2161: --- Summary: Add "types" collection to the schema element in the JSON model Key: CALCITE-2161 URL: https://issues.apache.org/jira/browse/CALCITE-2161 Project: Calcite Issue Type: Task Components: core Affects Versions: 1.16.0 Reporter: Shuyi Chen Assignee: Julian Hyde As discussed in CALCITE-2045, we need to add "types" collection in the schema element in the JSON model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2160) Spatial grid index, to accelerate polygon-to-polygon spatial joins
[
https://issues.apache.org/jira/browse/CALCITE-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2160:
-
Summary: Spatial grid index, to accelerate polygon-to-polygon spatial joins
(was: Spatial grid index)
> Spatial grid index, to accelerate polygon-to-polygon spatial joins
> --
>
> Key: CALCITE-2160
> URL: https://issues.apache.org/jira/browse/CALCITE-2160
> Project: Calcite
> Issue Type: Bug
> Components: spatial
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> Recognize materialized views that convert a geometry into a grid of
> rectangles, and use such materialized views for point-to-polygon and
> polgyon-to-polygon joins.
> Implement the [ST_MakeGrid|http://www.h2gis.org/docs/dev/ST_MakeGrid] and
> [ST_MakeGridPoints|http://www.h2gis.org/docs/dev/ST_MakeGridPoints] functions.
> Add a test data set based upon western U.S. states and national parks. Given
> a materialized view
> {code}CREATE MATERIALIZED VIEW StateGrids (name, x, y, PRIMARY KEY (name)) AS
> SELECT s.name, ST_XMin(g.the_geom), ST_YMin(g.the_geom)
> FROM States AS s
> CROSS APPLY TABLE(ST_MakeGrid(s.geom, 1, 1)) AS g{code}
> and a similar materialized view ParkGrids on Parks, the query
> {code}SELECT p.name AS park, s.name AS state
> FROM Parks AS p
> JOIN States AS s ON ST_Overlaps(s.geom, p.geom)
> ORDER BY 1, 2{code}
> should return
> {noformat}
> Park State
> =
> Death Valley CA
> Death Valley NV
> Yellowstone ID
> Yellowstone MT
> Yellowstone WY
> Yosemite CA
> {noformat}
> and should semi-join to the {{StateGrids}} and {{ParkGrids}} tables to reduce
> the size of the input before applying St_Overlaps: {code}SELECT p.name AS
> park, s.name AS state
> FROM Parks AS p
> JOIN States AS s ON ST_Overlaps(s.geom, p.geom)
> WHERE (p.name, s.name) IN (
> SELECT DISTINCT pg.name, sg.name
> FROM ParkGrids AS pg
> JOIN StateGrids AS sg ON pg.id = sg.id){code}
> Note the semi-join, to remove duplicates in case a park and a state have
> several cells that overlap.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2160) Spatial grid index
Julian Hyde created CALCITE-2160:
Summary: Spatial grid index
Key: CALCITE-2160
URL: https://issues.apache.org/jira/browse/CALCITE-2160
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
Recognize materialized views that convert a geometry into a grid of rectangles,
and use such materialized views for point-to-polygon and polgyon-to-polygon
joins.
Implement the [ST_MakeGrid|http://www.h2gis.org/docs/dev/ST_MakeGrid] and
[ST_MakeGridPoints|http://www.h2gis.org/docs/dev/ST_MakeGridPoints] functions.
Add a test data set based upon western U.S. states and national parks. Given a
materialized view
{code}CREATE MATERIALIZED VIEW StateGrids (name, x, y, PRIMARY KEY (name)) AS
SELECT s.name, ST_XMin(g.the_geom), ST_YMin(g.the_geom)
FROM States AS s
CROSS APPLY TABLE(ST_MakeGrid(s.geom, 1, 1)) AS g{code}
and a similar materialized view ParkGrids on Parks, the query
{code}SELECT p.name AS park, s.name AS state
FROM Parks AS p
JOIN States AS s ON ST_Overlaps(s.geom, p.geom)
ORDER BY 1, 2{code}
should return
{noformat}
Park State
=
Death Valley CA
Death Valley NV
Yellowstone ID
Yellowstone MT
Yellowstone WY
Yosemite CA
{noformat}
and should semi-join to the {{StateGrids}} and {{ParkGrids}} tables to reduce
the size of the input before applying St_Overlaps: {code}SELECT p.name AS park,
s.name AS state
FROM Parks AS p
JOIN States AS s ON ST_Overlaps(s.geom, p.geom)
WHERE (p.name, s.name) IN (
SELECT DISTINCT pg.name, sg.name
FROM ParkGrids AS pg
JOIN StateGrids AS sg ON pg.id = sg.id){code}
Note the semi-join, to remove duplicates in case a park and a state have
several cells that overlap.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2159) UNNEST to support 'ANY' type
Chunhui Shi created CALCITE-2159: Summary: UNNEST to support 'ANY' type Key: CALCITE-2159 URL: https://issues.apache.org/jira/browse/CALCITE-2159 Project: Calcite Issue Type: Bug Reporter: Chunhui Shi Assignee: Julian Hyde Not all data source has type information about the input of UNNEST during parsing stage. In Drill, if we want to support UNNEST(table.column) syntax for a document with nested structure, for now, these two things will happen: SqlUnnestOperator.inferReturnType will use unknown operand's type 'ANY' so isStruct will be false, thus the the following code will hit NULL reference. Another issue is, Should UnnestnameSpace.getTable return a table so when other parts of the query tried to refer to some columns coming out of UNNEST, we know the query is asking for a column from the table, so the parser could add the column to the RowType of UNNEST? An example query is like this: SELECT AVG(o.o_amount) AS avg_orders FROM UNNEST(c.orders) AS o -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2154) upgrade jackson
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2154: - Fix Version/s: avatica-1.11.0 > upgrade jackson > > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > Fix For: avatica-1.11.0, 1.16.0 > > > Calcite now uses FasterXML Jackson 2.6.3. Please upgrade to last version of > FasterXML Jackson (on 2018-01-30 it's version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > See also CALCITE-1021, KYLIN-3027. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2155) upgrade slf4j
[ https://issues.apache.org/jira/browse/CALCITE-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2155: - Labels: (was: third-party) > upgrade slf4j > - > > Key: CALCITE-2155 > URL: https://issues.apache.org/jira/browse/CALCITE-2155 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > > Apache Calcite depends on slf4j-api version 1.7.13 which was released on > 2015-11, more than two years ago. > We may wish to upgrade it to later version. For 2018-01-30, it's 1.7.25. > I hope that fixing pom.xml files and running tests is enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2155) upgrade slf4j
[ https://issues.apache.org/jira/browse/CALCITE-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2155: - Description: Apache Calcite depends on slf4j-api version 1.7.13 which was released on 2015-11, more than two years ago. We may wish to upgrade it to later version. For 2018-01-30, it's 1.7.25. I hope that fixing pom.xml files and running tests is enough. was: Apache Calcite depends on slf4j-api version 1.7.13 which was released on 2015-11, more than two years ago. It does not have known CVE vulnerabilities, but we may wish to upgrade it to later version. For 2018-01-30, it's 1.7.25. I hope that fixing pom.xml files and running tests is enough. > upgrade slf4j > - > > Key: CALCITE-2155 > URL: https://issues.apache.org/jira/browse/CALCITE-2155 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > Labels: third-party > > Apache Calcite depends on slf4j-api version 1.7.13 which was released on > 2015-11, more than two years ago. > We may wish to upgrade it to later version. For 2018-01-30, it's 1.7.25. > I hope that fixing pom.xml files and running tests is enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2154) upgrade jackson
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2154: - Fix Version/s: 1.16.0 > upgrade jackson > > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > Fix For: 1.16.0 > > > Calcite now uses FasterXML Jackson 2.6.3. Please upgrade to last version of > FasterXML Jackson (on 2018-01-30 it's version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > See also CALCITE-1021, KYLIN-3027. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2156) DateRangeRules not handling timestamp with local timezone properly
[
https://issues.apache.org/jira/browse/CALCITE-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345660#comment-16345660
]
Nishant Bangarwa commented on CALCITE-2156:
---
meant {{TIMESTAMP WITH LOCAL TIME ZONE}}
{{renamed Jira title.}}
> DateRangeRules not handling timestamp with local timezone properly
> --
>
> Key: CALCITE-2156
> URL: https://issues.apache.org/jira/browse/CALCITE-2156
> Project: Calcite
> Issue Type: Bug
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> DateRangeRules calculate floor and ceil on timestamp with local timezone in
> UTC timezone, instead it should do the floor or ceil on timestamp in local
> timezone when data type is timestamp with local timezone.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2156) DateRangeRules not handling timestamp with local timezone properly
[ https://issues.apache.org/jira/browse/CALCITE-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nishant Bangarwa updated CALCITE-2156: -- Summary: DateRangeRules not handling timestamp with local timezone properly (was: DateRangeRules not handling timestamp with timezone properly) > DateRangeRules not handling timestamp with local timezone properly > -- > > Key: CALCITE-2156 > URL: https://issues.apache.org/jira/browse/CALCITE-2156 > Project: Calcite > Issue Type: Bug >Reporter: Nishant Bangarwa >Assignee: Nishant Bangarwa >Priority: Major > > DateRangeRules calculate floor and ceil on timestamps in UTC timezone, > instead it should do the floor or ceil on timestamp in local timezone when > data type is timestamp with local timezone. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2154) upgrade jackson
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2154: - Labels: (was: cve security third-party) > upgrade jackson > > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > > Calcite now uses FasterXML Jackson 2.6.3. Please upgrade to last version of > FasterXML Jackson (on 2018-01-30 it's version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > See also CALCITE-1021, KYLIN-3027. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2156) DateRangeRules not handling timestamp with local timezone properly
[ https://issues.apache.org/jira/browse/CALCITE-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nishant Bangarwa updated CALCITE-2156: -- Description: DateRangeRules calculate floor and ceil on timestamp with local timezone in UTC timezone, instead it should do the floor or ceil on timestamp in local timezone when data type is timestamp with local timezone. (was: DateRangeRules calculate floor and ceil on timestamps in UTC timezone, instead it should do the floor or ceil on timestamp in local timezone when data type is timestamp with local timezone. ) > DateRangeRules not handling timestamp with local timezone properly > -- > > Key: CALCITE-2156 > URL: https://issues.apache.org/jira/browse/CALCITE-2156 > Project: Calcite > Issue Type: Bug >Reporter: Nishant Bangarwa >Assignee: Nishant Bangarwa >Priority: Major > > DateRangeRules calculate floor and ceil on timestamp with local timezone in > UTC timezone, instead it should do the floor or ceil on timestamp in local > timezone when data type is timestamp with local timezone. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2154) upgrade jackson
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2154: - Description: Calcite now uses FasterXML Jackson 2.6.3. Please upgrade to last version of FasterXML Jackson (on 2018-01-30 it's version 2.9.4). I hope that fixing pom.xml files and running tests is enough. See also CALCITE-1021, KYLIN-3027. was: Calcite now uses FasterXML Jackson 2.6.3 that has known security vulnerabilities: * CVE-2017-7525 is prone to a remote-code execution vulnerability. Successfully exploiting this issue allows attackers to execute arbitrary code in the context of the affected application. Failed exploits will result in denial-of-service conditions. * CVE-2017-15095 describes more deserialization exploits for jackson-databind as a follow-up to CVE-2017-7525. * CVE-2017-17485 is about jackson-databind up to 2.9.3 allowing unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 deserialization flaw. * CVE-2018-5968 is about jackson-databind up to 2.9.3 allowing unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 and CVE-2017-17485 deserialization flaws. Please upgrade to last version of FasterXML Jackson (on 2018-01-30 it's version 2.9.4). I hope that fixing pom.xml files and running tests is enough. (See also JIRA:CALCITE-1021, JIRA:KYLIN-3027) > upgrade jackson > > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > > Calcite now uses FasterXML Jackson 2.6.3. Please upgrade to last version of > FasterXML Jackson (on 2018-01-30 it's version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > See also CALCITE-1021, KYLIN-3027. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2154) upgrade jackson
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2154: - Component/s: avatica > upgrade jackson > > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > > Calcite now uses FasterXML Jackson 2.6.3. Please upgrade to last version of > FasterXML Jackson (on 2018-01-30 it's version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > See also CALCITE-1021, KYLIN-3027. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2156) DateRangeRules not handling timestamp with timezone properly
[
https://issues.apache.org/jira/browse/CALCITE-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345653#comment-16345653
]
Julian Hyde commented on CALCITE-2156:
--
Please clarify whether you mean {{TIMESTAMP WITH TIME ZONE}} or {{TIMESTAMP
WITH LOCAL TIME ZONE}}. They are different.
> DateRangeRules not handling timestamp with timezone properly
>
>
> Key: CALCITE-2156
> URL: https://issues.apache.org/jira/browse/CALCITE-2156
> Project: Calcite
> Issue Type: Bug
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> DateRangeRules calculate floor and ceil on timestamps in UTC timezone,
> instead it should do the floor or ceil on timestamp in local timezone when
> data type is timestamp with local timezone.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2158) SubQuery with EXISTS clause creates redundant aggregate call
Volodymyr Vysotskyi created CALCITE-2158:
Summary: SubQuery with EXISTS clause creates redundant aggregate
call
Key: CALCITE-2158
URL: https://issues.apache.org/jira/browse/CALCITE-2158
Project: Calcite
Issue Type: Bug
Reporter: Volodymyr Vysotskyi
Assignee: Julian Hyde
When {{SqlToRelConverter.Config.isExpand()}} returns true, subqueries are
expanded in {{SqlToRelConverter}}.
Then for the queries, like this:
{code:sql}
SELECT cs1.sal
FROM emp cs1
WHERE EXISTS
(SELECT *
FROM emp cs2
WHERE cs1.sal = cs2.sal
AND cs1.deptno <> cs2.deptno)
{code}
Calcite returns logical plan with excessive aggregate calls:
{noformat}
LogicalProject(SAL=[$5])
LogicalFilter(condition=[IS NOT NULL($9)])
LogicalCorrelate(correlation=[$cor0], joinType=[left], requiredColumns=[{5,
7}])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{}], agg#0=[MIN($0)])
LogicalProject($f0=[true])
LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3],
HIREDATE=[$4], SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
LogicalFilter(condition=[AND(=($cor0.SAL, $5), <>($cor0.DEPTNO,
$7))])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{noformat}
But when {{SqlToRelConverter.Config.isExpand()}} returns false and
SubQueryRemoveRule rules are applied to the logical plan with RexSubQuery, the
resulting logical plan is correct and does not contain excessive aggregate
calls:
{noformat}
LogicalProject(SAL=[$5])
LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
LogicalCorrelate(correlation=[$cor0], joinType=[inner],
requiredColumns=[{5, 7}])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{0}])
LogicalProject(i=[true])
LogicalFilter(condition=[AND(=($cor0.SAL, $5), <>($cor0.DEPTNO, $7))])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{noformat}
These cases may be observed using this unit test:
{code:java}
@Test public void testExistsExpand() {
final HepProgram preProgram = HepProgram.builder()
.addRuleInstance(SubQueryRemoveRule.FILTER)
.addRuleInstance(SubQueryRemoveRule.PROJECT)
.addRuleInstance(SubQueryRemoveRule.JOIN)
.build();
final HepProgram program = HepProgram.builder()
.build();
final String sql = "SELECT cs1.sal\n"
+ "FROM emp cs1 \n"
+ "WHEREEXISTS\n"
+ "(SELECT *\n"
+ "FROM emp cs2\n"
+ "WHERE cs1.sal = cs2.sal\n"
+ "ANDcs1.deptno <> cs2.deptno)";
sql(sql)
.withDecorrelation(false)
.withTrim(false)
.expand(true) // change to false
.withPre(preProgram)
.with(program)
.checkUnchanged();
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Baynes reassigned CALCITE-2157: - Assignee: Julian Hyde (was: Chris Baynes) > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Julian Hyde >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Baynes updated CALCITE-2157: -- External issue URL: (was: https://github.com/apache/calcite/pull/618) > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Chris Baynes >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Baynes updated CALCITE-2157: -- External issue URL: https://github.com/apache/calcite/pull/618 I have submitted a PR which provides a lot of the basic functionality. It currently does not yet support the ClickHouse join syntax. > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Assignee: Chris Baynes >Priority: Major > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2157) ClickHouse dialect implementation
Chris Baynes created CALCITE-2157: - Summary: ClickHouse dialect implementation Key: CALCITE-2157 URL: https://issues.apache.org/jira/browse/CALCITE-2157 Project: Calcite Issue Type: New Feature Components: jdbc-adapter Reporter: Chris Baynes Assignee: Chris Baynes ClickHouse is a really fast columnar DBMS for OLAP: [https://clickhouse.yandex/.|https://clickhouse.yandex/] It has a jdbc adapter and uses mostly standard sql, though there are differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2156) DateRangeRules not handling timestamp with timezone properly
Nishant Bangarwa created CALCITE-2156: - Summary: DateRangeRules not handling timestamp with timezone properly Key: CALCITE-2156 URL: https://issues.apache.org/jira/browse/CALCITE-2156 Project: Calcite Issue Type: Bug Reporter: Nishant Bangarwa Assignee: Nishant Bangarwa DateRangeRules calculate floor and ceil on timestamps in UTC timezone, instead it should do the floor or ceil on timestamp in local timezone when data type is timestamp with local timezone. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2156) DateRangeRules not handling timestamp with timezone properly
[ https://issues.apache.org/jira/browse/CALCITE-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345003#comment-16345003 ] Nishant Bangarwa commented on CALCITE-2156: --- [https://github.com/apache/calcite/pull/617] +cc [~julianhyde] found this during testing with hive, please review. > DateRangeRules not handling timestamp with timezone properly > > > Key: CALCITE-2156 > URL: https://issues.apache.org/jira/browse/CALCITE-2156 > Project: Calcite > Issue Type: Bug >Reporter: Nishant Bangarwa >Assignee: Nishant Bangarwa >Priority: Major > > DateRangeRules calculate floor and ceil on timestamps in UTC timezone, > instead it should do the floor or ceil on timestamp in local timezone when > data type is timestamp with local timezone. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2154) upgrade jackson
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16344721#comment-16344721 ] Alexey Roytman commented on CALCITE-2154: - It looks like Avatica also depends on jackson, and Avatica may also need an upgrade. > upgrade jackson > > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > Labels: cve, security, third-party > > Calcite now uses FasterXML Jackson 2.6.3 that has known security > vulnerabilities: > * CVE-2017-7525 is prone to a remote-code execution vulnerability. > Successfully exploiting this issue allows attackers to execute arbitrary code > in the context of the affected application. Failed exploits will result in > denial-of-service conditions. > * CVE-2017-15095 describes more deserialization exploits for > jackson-databind as a follow-up to CVE-2017-7525. > * CVE-2017-17485 is about jackson-databind up to 2.9.3 allowing > unauthenticated remote code execution because of an incomplete fix for the > CVE-2017-7525 deserialization flaw. > * CVE-2018-5968 is about jackson-databind up to 2.9.3 allowing > unauthenticated remote code execution because of an incomplete fix for the > CVE-2017-7525 and CVE-2017-17485 deserialization flaws. > Please upgrade to last version of FasterXML Jackson (on 2018-01-30 it's > version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > (See also JIRA:CALCITE-1021, JIRA:KYLIN-3027) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2154) upgrade jackson
[ https://issues.apache.org/jira/browse/CALCITE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Roytman updated CALCITE-2154: Labels: cve security third-party (was: cve security) > upgrade jackson > > > Key: CALCITE-2154 > URL: https://issues.apache.org/jira/browse/CALCITE-2154 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > Labels: cve, security, third-party > > Calcite now uses FasterXML Jackson 2.6.3 that has known security > vulnerabilities: > * CVE-2017-7525 is prone to a remote-code execution vulnerability. > Successfully exploiting this issue allows attackers to execute arbitrary code > in the context of the affected application. Failed exploits will result in > denial-of-service conditions. > * CVE-2017-15095 describes more deserialization exploits for > jackson-databind as a follow-up to CVE-2017-7525. > * CVE-2017-17485 is about jackson-databind up to 2.9.3 allowing > unauthenticated remote code execution because of an incomplete fix for the > CVE-2017-7525 deserialization flaw. > * CVE-2018-5968 is about jackson-databind up to 2.9.3 allowing > unauthenticated remote code execution because of an incomplete fix for the > CVE-2017-7525 and CVE-2017-17485 deserialization flaws. > Please upgrade to last version of FasterXML Jackson (on 2018-01-30 it's > version 2.9.4). > I hope that fixing pom.xml files and running tests is enough. > (See also JIRA:CALCITE-1021, JIRA:KYLIN-3027) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2155) upgrade slf4j
Alexey Roytman created CALCITE-2155: --- Summary: upgrade slf4j Key: CALCITE-2155 URL: https://issues.apache.org/jira/browse/CALCITE-2155 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.15.0 Reporter: Alexey Roytman Assignee: Julian Hyde Apache Calcite depends on slf4j-api version 1.7.13 which was released on 2015-11, more than two years ago. It does not have known CVE vulnerabilities, but we may wish to upgrade it to later version. For 2018-01-30, it's 1.7.25. I hope that fixing pom.xml files and running tests is enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2155) upgrade slf4j
[ https://issues.apache.org/jira/browse/CALCITE-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Roytman updated CALCITE-2155: Labels: third-party (was: ) > upgrade slf4j > - > > Key: CALCITE-2155 > URL: https://issues.apache.org/jira/browse/CALCITE-2155 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Alexey Roytman >Assignee: Julian Hyde >Priority: Major > Labels: third-party > > Apache Calcite depends on slf4j-api version 1.7.13 which was released on > 2015-11, more than two years ago. > It does not have known CVE vulnerabilities, but we may wish to upgrade it to > later version. For 2018-01-30, it's 1.7.25. > I hope that fixing pom.xml files and running tests is enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2154) upgrade jackson
Alexey Roytman created CALCITE-2154: --- Summary: upgrade jackson Key: CALCITE-2154 URL: https://issues.apache.org/jira/browse/CALCITE-2154 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.15.0 Reporter: Alexey Roytman Assignee: Julian Hyde Calcite now uses FasterXML Jackson 2.6.3 that has known security vulnerabilities: * CVE-2017-7525 is prone to a remote-code execution vulnerability. Successfully exploiting this issue allows attackers to execute arbitrary code in the context of the affected application. Failed exploits will result in denial-of-service conditions. * CVE-2017-15095 describes more deserialization exploits for jackson-databind as a follow-up to CVE-2017-7525. * CVE-2017-17485 is about jackson-databind up to 2.9.3 allowing unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 deserialization flaw. * CVE-2018-5968 is about jackson-databind up to 2.9.3 allowing unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 and CVE-2017-17485 deserialization flaws. Please upgrade to last version of FasterXML Jackson (on 2018-01-30 it's version 2.9.4). I hope that fixing pom.xml files and running tests is enough. (See also JIRA:CALCITE-1021, JIRA:KYLIN-3027) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
