[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL

2017-11-10 Thread Julian Hyde (JIRA)

[ 
https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248276#comment-16248276
 ] 

Julian Hyde commented on CALCITE-2045:
--

This would be perfect as part of the "server" module I am adding as part of 
CALCITE-707.

As a separate task, I also think we should add a type element to the JSON 
model, and "types" collection to the schema element in the JSON model, 
https://calcite.apache.org/docs/model.html#map-schema similar to its existing 
collections "tables" and "functions". It is probably better to do that task 
first, then it will be simple to add DDL support later.

Can you describe what syntax you were thinking for "CREATE TYPE"?

> Support "CREATE TYPE" DDL
> -
>
> Key: CALCITE-2045
> URL: https://issues.apache.org/jira/browse/CALCITE-2045
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (CALCITE-707) Built-in support for simple DDL statements

2017-11-10 Thread Julian Hyde (JIRA)

[ 
https://issues.apache.org/jira/browse/CALCITE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248274#comment-16248274
 ] 

Julian Hyde commented on CALCITE-707:
-

I am actively working on this and CALCITE-1991, creating a new "server" module. 
You can see work in progress in 
https://github.com/julianhyde/calcite/tree/707-ddl.

> Built-in support for simple DDL statements
> --
>
> Key: CALCITE-707
> URL: https://issues.apache.org/jira/browse/CALCITE-707
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> I would like Calcite to support simple DDL.
> DDL (and other commands such as KILL STATEMENT) make it possible to do a wide 
> range of operations over a REST or JDBC interface. We can't expect everything 
> do be done locally, using Java method calls.
> I expect that projects that use Calcite will define their own DDL. (In fact 
> Drill and Phoenix already do; see PHOENIX-1706.) Those projects are very 
> likely to have their own variations on CREATE TABLE etc. so they will want to 
> extend the parser. What I did in Phoenix (which was in turn adapted from 
> Drill) is a model that other projects can follow.
> But the base Calcite project should have CREATE TABLE, DROP TABLE, CREATE 
> SCHEMA, DROP SCHEMA, CREATE [ OR REPLACE ] VIEW etc.  There will be an AST 
> (extending SqlNode) for each of these commands, and a command-handler. Each 
> project that uses Calcite could extend those
> ASTs, but it would be fine if it built its own AST and command-handler.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (CALCITE-2045) Support "CREATE TYPE" DDL

2017-11-10 Thread Shuyi Chen (JIRA)

[ 
https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248028#comment-16248028
 ] 

Shuyi Chen edited comment on CALCITE-2045 at 11/10/17 9:09 PM:
---

Hi [~julianhyde], what do you think of supporting this in Calcite DDL? Or is it 
better to extend the parser in the project itself similar to Drill? 


was (Author: suez1224):
Hi [~julianhyde], what do you think of supporting this in Calcite DDL?

> Support "CREATE TYPE" DDL
> -
>
> Key: CALCITE-2045
> URL: https://issues.apache.org/jira/browse/CALCITE-2045
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (CALCITE-2046) Support "CREATE FUNCTION" DDL

2017-11-10 Thread Shuyi Chen (JIRA)

[ 
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248030#comment-16248030
 ] 

Shuyi Chen edited comment on CALCITE-2046 at 11/10/17 9:09 PM:
---

Hi [~julianhyde], what do you think of supporting this in Calcite DDL? Or is it 
better to extend the parser in the project itself similar to Drill? 


was (Author: suez1224):
Hi [~julianhyde], what do you think of supporting this in Calcite DDL?

> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
>  Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL

2017-11-10 Thread Shuyi Chen (JIRA)

[ 
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248030#comment-16248030
 ] 

Shuyi Chen commented on CALCITE-2046:
-

Hi [~julianhyde], what do you think of supporting this in Calcite DDL?

> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
>  Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL

2017-11-10 Thread Shuyi Chen (JIRA)

[ 
https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248028#comment-16248028
 ] 

Shuyi Chen commented on CALCITE-2045:
-

Hi [~julianhyde], what do you think of supporting this in Calcite DDL?

> Support "CREATE TYPE" DDL
> -
>
> Key: CALCITE-2045
> URL: https://issues.apache.org/jira/browse/CALCITE-2045
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (CALCITE-2039) AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..." and TableProjectableFilterable

2017-11-10 Thread Michael Mior (JIRA)

[ 
https://issues.apache.org/jira/browse/CALCITE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247955#comment-16247955
 ] 

Michael Mior commented on CALCITE-2039:
---

Thanks for sharing. It's a bit hard to follow what's going in your code, but 
I'm guessing you want to check over your projection logic to make sure the rows 
you return have the correct columns projected.

> AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..." 
> and TableProjectableFilterable
> 
>
> Key: CALCITE-2039
> URL: https://issues.apache.org/jira/browse/CALCITE-2039
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.14.0
>Reporter: Alexey Roytman
>Assignee: Michael Mior
> Attachments: CALCITE-2039.zip, calcite_2039_eclipse_project.zip
>
>
> When I use a ProjectableFilterableTable interface, the following query 
> (notice the "select 0 as c1, ...")
> {code}
> select 0 as c1, D101.c1 as c3, D101.c2 as c4, D101.c3 as c5 from (
>   select T101.Category as c1, T101.Revenue as c2,
>   T101."YEAR" as c3 from (
> select "YEAR", Category, "MONTH", Territory, Quarter, Sub_Category,
> Age_Group, Gender, Country, Revenue, Num_Of_Orders, "DATE" from
>   XSchema.HDP) T101) D101
> {code}
> causes an exception:
> {noformat}
> java.lang.AssertionError
>   at org.apache.calcite.util.mapping.Mappings.create(Mappings.java:64)
>   at org.apache.calcite.rel.core.Project.getMapping(Project.java:277)
>   at org.apache.calcite.rel.core.Project.getMapping(Project.java:257)
>   at 
> org.apache.calcite.rel.rules.ProjectTableScanRule.apply(ProjectTableScanRule.java:100)
>   at 
> org.apache.calcite.rel.rules.ProjectTableScanRule$3.onMatch(ProjectTableScanRule.java:83)
>   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:321)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
>   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)
> ...
> {noformat}
> In the Mappings.create(), mappingType is INVERSE_SURJECTION, and "assert 
> sourceCount >= targetCount" throws the exception, because sourceCount is 3, 
> and targetCount is 4.
> At the frame above, in Project.getMapping(), "projects" are: {{\[0, $1, $2, 
> $0\]}} (1st is RexLiteral, others are RexInputRef). At the frame above, in 
> EnumerableProject.getMapping(), getInput().getRowType() has only 3 fields in 
> the table.
> I have a reproduction case (in Java) but it's not within a Calcite standard.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)