[jira] [Commented] (CALCITE-1006) Enable maven-findbugs-plugin
[ https://issues.apache.org/jira/browse/CALCITE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443492#comment-16443492 ] Kevin Risden commented on CALCITE-1006: --- Looks like FindBugs is now SpotBugs. [http://spotbugs.readthedocs.io/en/latest/introduction.html] There are quite a few errors when this is added as a maven plugin. I can put up a PR for reference. > Enable maven-findbugs-plugin > > > Key: CALCITE-1006 > URL: https://issues.apache.org/jira/browse/CALCITE-1006 > Project: Calcite > Issue Type: Task > Components: build >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > > We can fairly trivially wire up the maven-findbugs-plugin to get some > static-analysis at build time. This is my tool of choice for the matter -- > I'll make sure we have some sane configuration and try to knock out any > issues that it reports. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2261) Switch calcite-core to JDK8
[
https://issues.apache.org/jira/browse/CALCITE-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443403#comment-16443403
]
Julian Hyde commented on CALCITE-2261:
--
Review comments:
* Can you use {{source=8 target=8}} rather than 1.8. The official name is JDK 8
not JDK 1.8.
* Make getSubSchema throw UnsupportedOperationException, to force sub-classes
to override.
* Add Bug.upgrade() somewhere to remind us to remove the workaround when we
upgrade to a version of janino that fixes the bug. Also mention the janino bug
number.
> Switch calcite-core to JDK8
> ---
>
> Key: CALCITE-2261
> URL: https://issues.apache.org/jira/browse/CALCITE-2261
> Project: Calcite
> Issue Type: Improvement
> Components: build
>Affects Versions: 1.16.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Currently (1.16) Calcilte core is compiled for JDK 1.7.
> Just switching maven-compiler-plugin to 1.8 is not enough because of a bug of
> Janino
> [https://github.com/janino-compiler/janino/issues/47]
> reported by Vova
>
> As a workaround to that bug we have to add a default method implementation
> for SchemaPlus#getSubSchema
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2266) Implement SQL 2016 JSON functions
Michael Mior created CALCITE-2266: - Summary: Implement SQL 2016 JSON functions Key: CALCITE-2266 URL: https://issues.apache.org/jira/browse/CALCITE-2266 Project: Calcite Issue Type: Improvement Components: core Reporter: Michael Mior Assignee: Michael Mior -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2262) In Druid adapter, allow count(*) to be pushed when other aggregate functions are present
[
https://issues.apache.org/jira/browse/CALCITE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443200#comment-16443200
]
Julian Hyde commented on CALCITE-2262:
--
Someone evidently created a release 1.16.1 and now it shows up every time. Do
your best to figure out the actual release where it was fixed.
> In Druid adapter, allow count(*) to be pushed when other aggregate functions
> are present
>
>
> Key: CALCITE-2262
> URL: https://issues.apache.org/jira/browse/CALCITE-2262
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Labels: improvement
> Fix For: 1.16.1
>
>
> Currently only {code}select count(*) from druid_table {code} is pushed as
> Timeseries.
> The goal of this patch is to allow the push of more complicated queries like
> {code} select count(*), sum(metric) from table {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1206) Push HAVING, ORDER BY and LIMIT into Druid
[ https://issues.apache.org/jira/browse/CALCITE-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443197#comment-16443197 ] Julian Hyde commented on CALCITE-1206: -- Make sure there are tests, then feel free to close. > Push HAVING, ORDER BY and LIMIT into Druid > -- > > Key: CALCITE-1206 > URL: https://issues.apache.org/jira/browse/CALCITE-1206 > Project: Calcite > Issue Type: Bug > Components: druid >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > > Push HAVING, ORDER BY and LIMIT into Druid. This extends the basic Druid > adapter added in CALCITE-1121. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1775) Druid adapter: "GROUP BY ()" on empty relation should return 1 row
[
https://issues.apache.org/jira/browse/CALCITE-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443196#comment-16443196
]
Julian Hyde commented on CALCITE-1775:
--
Sure. It seems that several Druid issues were fixed all at once. Probably good
to make sure that there are tests in DruidAdapterIT so that we don't regress.
> Druid adapter: "GROUP BY ()" on empty relation should return 1 row
> --
>
> Key: CALCITE-1775
> URL: https://issues.apache.org/jira/browse/CALCITE-1775
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> A "GROUP BY ()" query on an empty relation should return 1 row, but currently
> returns 0 rows.
> Test case in {{DruidAdapterIT}}:
> {code}
> @Test public void testSelectCountEmpty() {
> sql("select count(*) as c from \"foodmart\" where \"product_id\" < 0")
> .returnsUnordered("C=0");
> }
> {code}
> The query should return one row, but returns 0 rows.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2265) Strange cast created for ROW comparison
Dylan Adams created CALCITE-2265:
Summary: Strange cast created for ROW comparison
Key: CALCITE-2265
URL: https://issues.apache.org/jira/browse/CALCITE-2265
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.16.0
Reporter: Dylan Adams
Assignee: Julian Hyde
A comparison using ROWs results in queries that can't be executed by the
database due to strange casts like
{noformat}
CAST(ROW('Blake', 'Manager') AS ROW){noformat}
Direct query against HSQLDB:
{noformat}
sqlline> !connect jdbc:hsqldb:res:scott SCOTT TIGER
...
0: jdbc:hsqldb:res:scott> SELECT empno FROM emp WHERE (ename, job) < ('Blake',
'Manager');
++
| EMPNO |
++
| 7499 |
| 7698 |
| 7876 |
++{noformat}
Query through calcite:
{noformat}
sqlline> !connect
jdbc:calcite:schemaType=jdbc;schema.jdbcDriver=org.hsqldb.jdbcDriver;schema.jdbcUrl=jdbc:hsqldb:res:scott;schema.jdbcUser=SCOTT;schema.jdbcPassword=TIGER
SCOTT TIGER
Connecting to
jdbc:calcite:schemaType=jdbc;schema.jdbcDriver=org.hsqldb.jdbcDriver;schema.jdbcUrl=jdbc:hsqldb:res:scott;schema.jdbcUser=SCOTT;schema.jdbcPassword=TIGER
...
Connected to: Calcite (version 1.17.0-SNAPSHOT)
Driver: Calcite JDBC Driver (version 1.17.0-SNAPSHOT)
Autocommit status: true
Transaction isolation: TRANSACTION_REPEATABLE_READ
0: jdbc:calcite:schemaType=jdbc> SELECT empno FROM emp WHERE (ename, job) <
('Blake', 'Manager');
Error: Error while executing SQL "SELECT empno FROM emp WHERE (ename, job) <
('Blake', 'Manager')": while executing SQL [SELECT "EMPNO"
FROM "EMP"
WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
(state=,code=0)
java.sql.SQLException: Error while executing SQL "SELECT empno FROM emp WHERE
(ename, job) < ('Blake', 'Manager')": while executing SQL [SELECT "EMPNO"
FROM "EMP"
WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
at
org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:209)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
Caused by: java.lang.RuntimeException: while executing SQL [SELECT "EMPNO"
FROM "EMP"
WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
at
org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
at
org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:82)
at
org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
at org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
at org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
at
org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
... 7 more
Caused by: java.sql.SQLSyntaxErrorException: type not found or user lacks
privilege: ROW
at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
at
org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
at
org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
at
org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
... 16 more
Caused by: org.hsqldb.HsqlException: type not found or user lacks privilege: ROW
at org.hsqldb.error.Error.error(Unknown Source)
at org.hsqldb.error.Error.error(Unknown Source)
at org.hsqldb.ParserDQL.readTypeDefinition(Unknown Source)
at org.hsqldb.ParserDQL.readCastExpressionOrNull(Unknown Source)
at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown Source)
at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown Source)
at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown Source)
at org.hsqldb.ParserDQL.XreadRowOrCommonValueExpression(Unknown Source)
at
[jira] [Commented] (CALCITE-1591) Druid adapter: Use "groupBy" query with extractionFn for time dimension
[
https://issues.apache.org/jira/browse/CALCITE-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443028#comment-16443028
]
slim bouguerra commented on CALCITE-1591:
-
i think this one can be closed too, we are using Extraction functions to
project expression on the top of Druid columns.
> Druid adapter: Use "groupBy" query with extractionFn for time dimension
> ---
>
> Key: CALCITE-1591
> URL: https://issues.apache.org/jira/browse/CALCITE-1591
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> For queries that aggregate on the time dimension, or a function of it such as
> {{FLOOR(__time TO DAY)}}, as of the fix for CALCITE-1579 we generate a
> "groupBy" query that does not sort or apply limit. It would be better (in the
> sense that Druid is doing more of the work, and Hive is doing less work) if
> we use an extractionFn to create a dimension that we can sort on.
> In CALCITE-1578, [~nishantbangarwa] gives the following example query:
> {code}
> {
> "queryType": "groupBy",
> "dataSource": "druid_tpcds_ss_sold_time_subset",
> "granularity": "ALL",
> "dimensions": [
> "i_brand_id",
> {
> "type" : "extraction",
> "dimension" : "__time",
> "outputName" : "year",
> "extractionFn" : {
> "type" : "timeFormat",
> "granularity" : "YEAR"
> }
> }
> ],
> "limitSpec": {
> "type": "default",
> "limit": 10,
> "columns": [
> {
> "dimension": "$f3",
> "direction": "ascending"
> }
> ]
> },
> "aggregations": [
> {
> "type": "longMax",
> "name": "$f2",
> "fieldName": "ss_quantity"
> },
> {
> "type": "doubleSum",
> "name": "$f3",
> "fieldName": "ss_wholesale_cost"
> }
> ],
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ]
> }
> {code}
> and for {{DruidAdapterIt. testGroupByDaySortDescLimit}}, [~bslim] suggests
> {code}
> {
> "queryType": "groupBy",
> "dataSource": "foodmart",
> "granularity": "all",
> "dimensions": [
> "brand_name",
> {
> "type": "extraction",
> "dimension": "__time",
> "outputName": "day",
> "extractionFn": {
> "type": "timeFormat",
> "granularity": "DAY"
> }
> }
> ],
> "aggregations": [
> {
> "type": "longSum",
> "name": "S",
> "fieldName": "unit_sales"
> }
> ],
> "limitSpec": {
> "type": "default",
> "limit": 30,
> "columns": [
> {
> "dimension": "S",
> "direction": "ascending"
> }
> ]
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1775) Druid adapter: "GROUP BY ()" on empty relation should return 1 row
[
https://issues.apache.org/jira/browse/CALCITE-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
slim bouguerra updated CALCITE-1775:
Fix Version/s: 1.16.0
> Druid adapter: "GROUP BY ()" on empty relation should return 1 row
> --
>
> Key: CALCITE-1775
> URL: https://issues.apache.org/jira/browse/CALCITE-1775
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> A "GROUP BY ()" query on an empty relation should return 1 row, but currently
> returns 0 rows.
> Test case in {{DruidAdapterIT}}:
> {code}
> @Test public void testSelectCountEmpty() {
> sql("select count(*) as c from \"foodmart\" where \"product_id\" < 0")
> .returnsUnordered("C=0");
> }
> {code}
> The query should return one row, but returns 0 rows.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1775) Druid adapter: "GROUP BY ()" on empty relation should return 1 row
[
https://issues.apache.org/jira/browse/CALCITE-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443026#comment-16443026
]
slim bouguerra commented on CALCITE-1775:
-
I think we can close this since it was fixed already.
> Druid adapter: "GROUP BY ()" on empty relation should return 1 row
> --
>
> Key: CALCITE-1775
> URL: https://issues.apache.org/jira/browse/CALCITE-1775
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> A "GROUP BY ()" query on an empty relation should return 1 row, but currently
> returns 0 rows.
> Test case in {{DruidAdapterIT}}:
> {code}
> @Test public void testSelectCountEmpty() {
> sql("select count(*) as c from \"foodmart\" where \"product_id\" < 0")
> .returnsUnordered("C=0");
> }
> {code}
> The query should return one row, but returns 0 rows.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1718) Incorrect data type for context in Druid adapter
[
https://issues.apache.org/jira/browse/CALCITE-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443021#comment-16443021
]
slim bouguerra commented on CALCITE-1718:
-
[~michaelmior] shall we mark this as fixed?
> Incorrect data type for context in Druid adapter
>
>
> Key: CALCITE-1718
> URL: https://issues.apache.org/jira/browse/CALCITE-1718
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Michael Mior
>Assignee: Michael Mior
>Priority: Major
>
> The context {{skipEmptyBuckets}} added in
> [CALCITE-1589|https://issues.apache.org/jira/browse/CALCITE-1589] was given
> the boolean value {{true}}. The [Druid
> documentation|http://druid.io/docs/latest/querying/timeseriesquery.html]
> shows that this should be the string {{"true"}}. I get a test failure on
> Druid 0.9.2 because of this discrepancy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1206) Push HAVING, ORDER BY and LIMIT into Druid
[ https://issues.apache.org/jira/browse/CALCITE-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443018#comment-16443018 ] slim bouguerra commented on CALCITE-1206: - [~julianhyde] i think we push most of this to Druid after 1.16.0, Shall we mark this as fixed or you have more ideas? > Push HAVING, ORDER BY and LIMIT into Druid > -- > > Key: CALCITE-1206 > URL: https://issues.apache.org/jira/browse/CALCITE-1206 > Project: Calcite > Issue Type: Bug > Components: druid >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > > Push HAVING, ORDER BY and LIMIT into Druid. This extends the basic Druid > adapter added in CALCITE-1121. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2119) Druid Filter validation Logic broken for filters like column_A = column_B
[
https://issues.apache.org/jira/browse/CALCITE-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
slim bouguerra updated CALCITE-2119:
Fix Version/s: 1.16.0
> Druid Filter validation Logic broken for filters like column_A = column_B
> -
>
> Key: CALCITE-2119
> URL: https://issues.apache.org/jira/browse/CALCITE-2119
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.15.0
>Reporter: slim bouguerra
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently, the logic for Filter tree validation and Filter translation to
> Druid native JSON is in a two different functions.
> Ideal to avoid this kind of runtime exceptions, we can blend both path of
> +Filter push down validation function
> +org.apache.calcite.adapter.druid.DruidQuery#isValidFilter(org.apache.calcite.rex.RexNode)
> and the +Translation function
> +org.apache.calcite.adapter.druid.DruidQuery.Translator#translateFilter.
> IMO, an easy implementation will be to try generating Druid native filter
> treat exceptions or null instance as it can not be pushed down. This will
> make code more readable and less duplication of logic that leads to fewer
> runtime exceptions.
> The following test
> {code}
> @Test
> public void testFilterColumnAEqColumnB() {
> final String sql = "SELECT count(*) from \"foodmart\" where
> \"product_id\" = \"city\"";
> sql(sql, FOODMART).runs();
> }
> {code}
> retruns
> {code}
> java.lang.AssertionError: it is not a valid comparison: =($1, $29)
> at
> org.apache.calcite.adapter.druid.DruidQuery$Translator.translateFilter(DruidQuery.java:1234)
> at
> org.apache.calcite.adapter.druid.DruidQuery$Translator.access$000(DruidQuery.java:1114)
> at
> org.apache.calcite.adapter.druid.DruidQuery.getQuery(DruidQuery.java:525)
> at
> org.apache.calcite.adapter.druid.DruidQuery.deriveQuerySpec(DruidQuery.java:495)
> at
> org.apache.calcite.adapter.druid.DruidQuery.getQuerySpec(DruidQuery.java:434)
> at
> org.apache.calcite.adapter.druid.DruidQuery.deriveRowType(DruidQuery.java:324)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:224)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:857)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.adapter.druid.DruidRules$DruidFilterRule.onMatch(DruidRules.java:283)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:319)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:781)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:568)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.runs(CalciteAssert.java:1407)
> at
> org.apache.calcite.test.DruidAdapterIT.testFilterColumnAEqColumnB(DruidAdapterIT.java:3494)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Closed] (CALCITE-2119) Druid Filter validation Logic broken for filters like column_A = column_B
[
https://issues.apache.org/jira/browse/CALCITE-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
slim bouguerra closed CALCITE-2119.
---
Resolution: Fixed
Assignee: slim bouguerra (was: Julian Hyde)
> Druid Filter validation Logic broken for filters like column_A = column_B
> -
>
> Key: CALCITE-2119
> URL: https://issues.apache.org/jira/browse/CALCITE-2119
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.15.0
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently, the logic for Filter tree validation and Filter translation to
> Druid native JSON is in a two different functions.
> Ideal to avoid this kind of runtime exceptions, we can blend both path of
> +Filter push down validation function
> +org.apache.calcite.adapter.druid.DruidQuery#isValidFilter(org.apache.calcite.rex.RexNode)
> and the +Translation function
> +org.apache.calcite.adapter.druid.DruidQuery.Translator#translateFilter.
> IMO, an easy implementation will be to try generating Druid native filter
> treat exceptions or null instance as it can not be pushed down. This will
> make code more readable and less duplication of logic that leads to fewer
> runtime exceptions.
> The following test
> {code}
> @Test
> public void testFilterColumnAEqColumnB() {
> final String sql = "SELECT count(*) from \"foodmart\" where
> \"product_id\" = \"city\"";
> sql(sql, FOODMART).runs();
> }
> {code}
> retruns
> {code}
> java.lang.AssertionError: it is not a valid comparison: =($1, $29)
> at
> org.apache.calcite.adapter.druid.DruidQuery$Translator.translateFilter(DruidQuery.java:1234)
> at
> org.apache.calcite.adapter.druid.DruidQuery$Translator.access$000(DruidQuery.java:1114)
> at
> org.apache.calcite.adapter.druid.DruidQuery.getQuery(DruidQuery.java:525)
> at
> org.apache.calcite.adapter.druid.DruidQuery.deriveQuerySpec(DruidQuery.java:495)
> at
> org.apache.calcite.adapter.druid.DruidQuery.getQuerySpec(DruidQuery.java:434)
> at
> org.apache.calcite.adapter.druid.DruidQuery.deriveRowType(DruidQuery.java:324)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:224)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:857)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.adapter.druid.DruidRules$DruidFilterRule.onMatch(DruidRules.java:283)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:319)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:781)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:568)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.runs(CalciteAssert.java:1407)
> at
> org.apache.calcite.test.DruidAdapterIT.testFilterColumnAEqColumnB(DruidAdapterIT.java:3494)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Commented] (CALCITE-2262) In Druid adapter, allow count(*) to be pushed when other aggregate functions are present
[
https://issues.apache.org/jira/browse/CALCITE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443012#comment-16443012
]
slim bouguerra commented on CALCITE-2262:
-
[~julianhyde] not sure, currently that is what Jira shows first when i select
fix version, please feel free to set the right version.
> In Druid adapter, allow count(*) to be pushed when other aggregate functions
> are present
>
>
> Key: CALCITE-2262
> URL: https://issues.apache.org/jira/browse/CALCITE-2262
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Labels: improvement
> Fix For: 1.16.1
>
>
> Currently only {code}select count(*) from druid_table {code} is pushed as
> Timeseries.
> The goal of this patch is to allow the push of more complicated queries like
> {code} select count(*), sum(metric) from table {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2262) In Druid adapter, allow count(*) to be pushed when other aggregate functions are present
[
https://issues.apache.org/jira/browse/CALCITE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443006#comment-16443006
]
Julian Hyde commented on CALCITE-2262:
--
What is release 1.16.1? We don't generally do patch releases.
> In Druid adapter, allow count(*) to be pushed when other aggregate functions
> are present
>
>
> Key: CALCITE-2262
> URL: https://issues.apache.org/jira/browse/CALCITE-2262
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Labels: improvement
> Fix For: 1.16.1
>
>
> Currently only {code}select count(*) from druid_table {code} is pushed as
> Timeseries.
> The goal of this patch is to allow the push of more complicated queries like
> {code} select count(*), sum(metric) from table {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2262) In Druid adapter, allow count(*) to be pushed when other aggregate functions are present
[
https://issues.apache.org/jira/browse/CALCITE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2262:
-
Summary: In Druid adapter, allow count(*) to be pushed when other aggregate
functions are present (was: Allow count(*) to be pushed with other aggregators
to Druid Storage Handler.)
> In Druid adapter, allow count(*) to be pushed when other aggregate functions
> are present
>
>
> Key: CALCITE-2262
> URL: https://issues.apache.org/jira/browse/CALCITE-2262
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Labels: improvement
> Fix For: 1.16.1
>
>
> Currently only {code}select count(*) from druid_table {code} is pushed as
> Timeseries.
> The goal of this patch is to allow the push of more complicated queries like
> {code} select count(*), sum(metric) from table {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2264) User defined function in json schema pushed to jdbc subschema.
[
https://issues.apache.org/jira/browse/CALCITE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442622#comment-16442622
]
Piotr Bojko commented on CALCITE-2264:
--
Here https://github.com/ptrbojko/calcite/tree/CALCITE-2088-more-tests-01 you
can see the bug.
> User defined function in json schema pushed to jdbc subschema.
> --
>
> Key: CALCITE-2264
> URL: https://issues.apache.org/jira/browse/CALCITE-2264
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Considering chinook tests, having following schema:
> {code:json}
> {
> "version": "1.0",
> "defaultSchema": "ENHANCED",
> "schemas": [
> {
> "name": "CHINOOK",
> "type": "jdbc",
> "jdbcDriver": "org.hsqldb.jdbc.JDBCDriver",
> "jdbcUrl": "jdbc:hsqldb:res:chinook",
> "jdbcUser": "sa",
> "jdbcPassword": ""
> },
> {
> "name": "ENHANCED",
> "type": "custom",
> "factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
> "operand": {},
> "tables": [
> ...
> {
> "name" : "SIMPLE_CUSTOMER",
> "type" : "view",
> "sql" : [
> "SELECT c.firstname, c.lastname, c.email ",
> "FROM chinook.customer AS c"
> ]
> ...
> ],
> "functions": [
> {
> "name": "ASCONCATOFPARAMS",
> "className": "org.apache.calcite.chinook.StringConcatFunction"
> }
> ]
> }
> ]
> {code}
> Following query produces error:
> {code:sql}
> SELECT email, ASCONCATOFPARAMS(firstname, lastname) AS joined FROM
> SIMPLE_CUSTOMER limit 3
> {code}
> Exception:
> {code}
> > Caused by: java.lang.RuntimeException: while executing SQL [SELECT "EMAIL"
> > AS "email", "ASCONCATOFPARAMS"("FIRSTNAME", "LASTNAME") AS "joined"
> > FROM (SELECT *
> > FROM "CUSTOMER"
> > LIMIT 3) AS "t"]
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> > at
> > org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> > at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
> > at
> > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> > at
> > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> > ... 24 more
> > Caused by: java.sql.SQLSyntaxErrorException: user lacks privilege or object
> > not found: ASCONCATOFPARAMS
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> > ... 33 more
> > Caused by: org.hsqldb.HsqlException: user lacks privilege or object not
> > found: ASCONCATOFPARAMS
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.Routine.getMethods(Unknown Source)
> > at org.hsqldb.Routine.createRoutines(Unknown Source)
> > at org.hsqldb.ParserDQL.readColumnOrFunctionExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadValueExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSelect(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadQuerySpecification(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleTable(Unknown Source)
> > at
[jira] [Created] (CALCITE-2264) User defined function in json schema pushed to jdbc subschema.
Piotr Bojko created CALCITE-2264:
Summary: User defined function in json schema pushed to jdbc
subschema.
Key: CALCITE-2264
URL: https://issues.apache.org/jira/browse/CALCITE-2264
Project: Calcite
Issue Type: Bug
Reporter: Piotr Bojko
Assignee: Julian Hyde
Considering chinook tests, having following schema:
{code:json}
{
"version": "1.0",
"defaultSchema": "ENHANCED",
"schemas": [
{
"name": "CHINOOK",
"type": "jdbc",
"jdbcDriver": "org.hsqldb.jdbc.JDBCDriver",
"jdbcUrl": "jdbc:hsqldb:res:chinook",
"jdbcUser": "sa",
"jdbcPassword": ""
},
{
"name": "ENHANCED",
"type": "custom",
"factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
"operand": {},
"tables": [
...
{
"name" : "SIMPLE_CUSTOMER",
"type" : "view",
"sql" : [
"SELECT c.firstname, c.lastname, c.email ",
"FROM chinook.customer AS c"
]
...
],
"functions": [
{
"name": "ASCONCATOFPARAMS",
"className": "org.apache.calcite.chinook.StringConcatFunction"
}
]
}
]
{code}
Following query produces error:
{code:sql}
SELECT email, ASCONCATOFPARAMS(firstname, lastname) AS joined FROM
SIMPLE_CUSTOMER limit 3
{code}
Exception:
{code}
> Caused by: java.lang.RuntimeException: while executing SQL [SELECT "EMAIL" AS
> "email", "ASCONCATOFPARAMS"("FIRSTNAME", "LASTNAME") AS "joined"
> FROM (SELECT *
> FROM "CUSTOMER"
> LIMIT 3) AS "t"]
> at
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> at
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> ... 24 more
> Caused by: java.sql.SQLSyntaxErrorException: user lacks privilege or object
> not found: ASCONCATOFPARAMS
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> at
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> at
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> at
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> ... 33 more
> Caused by: org.hsqldb.HsqlException: user lacks privilege or object not
> found: ASCONCATOFPARAMS
> at org.hsqldb.error.Error.error(Unknown Source)
> at org.hsqldb.error.Error.error(Unknown Source)
> at org.hsqldb.Routine.getMethods(Unknown Source)
> at org.hsqldb.Routine.createRoutines(Unknown Source)
> at org.hsqldb.ParserDQL.readColumnOrFunctionExpression(Unknown Source)
> at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown
> Source)
> at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown
> Source)
> at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
> at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
> at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
> at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown
> Source)
> at org.hsqldb.ParserDQL.XreadValueExpression(Unknown Source)
> at org.hsqldb.ParserDQL.XreadSelect(Unknown Source)
> at org.hsqldb.ParserDQL.XreadQuerySpecification(Unknown Source)
> at org.hsqldb.ParserDQL.XreadSimpleTable(Unknown Source)
> at org.hsqldb.ParserDQL.XreadQueryPrimary(Unknown Source)
> at org.hsqldb.ParserDQL.XreadQueryTerm(Unknown Source)
> at org.hsqldb.ParserDQL.XreadQueryExpressionBody(Unknown Source)
> at org.hsqldb.ParserDQL.XreadQueryExpression(Unknown Source)
> at org.hsqldb.ParserDQL.compileCursorSpecification(Unknown Source)
> at org.hsqldb.ParserCommand.compilePart(Unknown Source)
> at org.hsqldb.ParserCommand.compileStatements(Unknown Source)
> at
[jira] [Commented] (CALCITE-1993) Possible bug - NPE when using H2
[
https://issues.apache.org/jira/browse/CALCITE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442544#comment-16442544
]
Piotr Bojko commented on CALCITE-1993:
--
[~julianhyde] are you ok with closing this issue?
> Possible bug - NPE when using H2
>
>
> Key: CALCITE-1993
> URL: https://issues.apache.org/jira/browse/CALCITE-1993
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
> Environment: JIRA Container. Developed code is part of JIRA addon.
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I've receiving NPE When using Calcite. My code is as follows
> {code:java}
> @Autowired
> public CalciteBootstrap(DatasourceProvider datasourceProvider) throws
> SQLException {
> this.datasource = datasourceProvider.fetchDatasource();
> log.debug("Datasource fetched - {}", datasource);
> this.connection = createRootSchema();
> this.schema = JdbcSchema.create(connection.getRootSchema(), "PUBLIC",
> datasource, null, null);
> connection.getRootSchema().add("jira", schema);
> connection.createStatement().executeQuery("select * from
> jira.PROJECT_KEY");
> }
> private CalciteConnection createRootSchema() {
> try {
> Class.forName("org.apache.calcite.jdbc.Driver");
> Properties info = new Properties();
> info.setProperty("lex", "JAVA");
> Connection connection = DriverManager.getConnection("jdbc:calcite:",
> info);
> CalciteConnection calciteConnection
> = connection.unwrap(CalciteConnection.class);
> return calciteConnection;
> } catch (SQLException | ClassNotFoundException ex) {
> throw new RuntimeException(ex);
> }
> }
> {code}
> And NPE:
> {noformat}
> [INFO] [talledLocalContainer] java.sql.SQLException: Error while executing
> SQL "select * from jira.PROJECT_KEY": null
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> [INFO] [talledLocalContainer] at
> com.codedoers.jira.smartql.QueryController.request(QueryController.java:23)
> ...
> [INFO] [talledLocalContainer] Caused by: java.lang.NullPointerException
> [INFO] [talledLocalContainer] at Baz.bind(Unknown Source)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:335)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:294)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:559)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:550)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:607)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> [INFO] [talledLocalContainer] ... 240 more
> {noformat}
> I am developing an addon for JIRA, hence the container is JIRA. DB is H2. I
> am borrowing JIRAs datasource for Calcite.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2263) Wrong start Pos of SqlOrderBy
[
https://issues.apache.org/jira/browse/CALCITE-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wenlong Lyu updated CALCITE-2263:
-
Summary: Wrong start Pos of SqlOrderBy (was: Wrong start Pos in SqlOrderBy)
> Wrong start Pos of SqlOrderBy
> -
>
> Key: CALCITE-2263
> URL: https://issues.apache.org/jira/browse/CALCITE-2263
> Project: Calcite
> Issue Type: Bug
>Reporter: Wenlong Lyu
>Assignee: Julian Hyde
>Priority: Major
>
> currently, start pos of SqlOrderBy is pos of limit, by I think it should be
> the start pos of the ordered query.
> {code:java}
> // Parser.jj
> if (orderBy != null || start != null || count != null) {
> if (orderBy == null) {
> orderBy = SqlNodeList.EMPTY;
> }
> e = new SqlOrderBy(getPos(), e, orderBy, start, count);
> }
> return e;{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2263) Wrong start Pos in SqlOrderBy
[
https://issues.apache.org/jira/browse/CALCITE-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wenlong Lyu updated CALCITE-2263:
-
Description:
currently, start pos of SqlOrderBy is pos of limit, by I think it should be the
start pos of the ordered query.
{code:java}
// Parser.jj
if (orderBy != null || start != null || count != null) {
if (orderBy == null) {
orderBy = SqlNodeList.EMPTY;
}
e = new SqlOrderBy(getPos(), e, orderBy, start, count);
}
return e;{code}
was:
{code:java}
// Parser.jj
if (orderBy != null || start != null || count != null) {
if (orderBy == null) {
orderBy = SqlNodeList.EMPTY;
}
e = new SqlOrderBy(getPos(), e, orderBy, start, count);
}
return e;{code}
> Wrong start Pos in SqlOrderBy
> -
>
> Key: CALCITE-2263
> URL: https://issues.apache.org/jira/browse/CALCITE-2263
> Project: Calcite
> Issue Type: Bug
>Reporter: Wenlong Lyu
>Assignee: Julian Hyde
>Priority: Major
>
> currently, start pos of SqlOrderBy is pos of limit, by I think it should be
> the start pos of the ordered query.
> {code:java}
> // Parser.jj
> if (orderBy != null || start != null || count != null) {
> if (orderBy == null) {
> orderBy = SqlNodeList.EMPTY;
> }
> e = new SqlOrderBy(getPos(), e, orderBy, start, count);
> }
> return e;{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2263) Wrong start Pos in SqlOrderBy
Wenlong Lyu created CALCITE-2263:
Summary: Wrong start Pos in SqlOrderBy
Key: CALCITE-2263
URL: https://issues.apache.org/jira/browse/CALCITE-2263
Project: Calcite
Issue Type: Bug
Reporter: Wenlong Lyu
Assignee: Julian Hyde
{code:java}
// Parser.jj
if (orderBy != null || start != null || count != null) {
if (orderBy == null) {
orderBy = SqlNodeList.EMPTY;
}
e = new SqlOrderBy(getPos(), e, orderBy, start, count);
}
return e;{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-2209) Support loading JSON model file through URL
[ https://issues.apache.org/jira/browse/CALCITE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen reassigned CALCITE-2209: --- Assignee: Julian Hyde (was: Shuyi Chen) > Support loading JSON model file through URL > --- > > Key: CALCITE-2209 > URL: https://issues.apache.org/jira/browse/CALCITE-2209 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Julian Hyde >Priority: Major > > Currently, Calcite only support loading JSON model file through inline or > local file. The Jira attemps to extend it to support loading JSON model file > through URL, so users can implement their own URLStreamHandlerFactory to read > the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2209) Support loading JSON model file through URL
[ https://issues.apache.org/jira/browse/CALCITE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen reassigned CALCITE-2209: --- Assignee: Shuyi Chen (was: Julian Hyde) > Support loading JSON model file through URL > --- > > Key: CALCITE-2209 > URL: https://issues.apache.org/jira/browse/CALCITE-2209 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > Currently, Calcite only support loading JSON model file through inline or > local file. The Jira attemps to extend it to support loading JSON model file > through URL, so users can implement their own URLStreamHandlerFactory to read > the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
