As I noted in https://issues.apache.org/jira/browse/CALCITE-2464 
<https://issues.apache.org/jira/browse/CALCITE-2464>, SQL struct types do not 
behave exactly like Java classes (more like Java value types). If the semantics 
are not as desired, maybe we’ll have to design a new type constructor.

Since Calcite is grounded in SQL, I would encourage people to give examples in 
terms of SQL (DDL, queries, results), not just in terms of the Java APIs.

Lastly, I’ll draw your attention to Shuyi’s great work on “CREATE TYPE” (see 
https://issues.apache.org/jira/browse/CALCITE-2045 
<https://issues.apache.org/jira/browse/CALCITE-2045>). He extended DDL in the 
“server” module, so you can try out his examples.

Julian


> On Aug 11, 2018, at 9:03 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> 
> wrote:
> 
> Just to clarify the use case: I'm building SQL plugin to analyze Java heap
> dumps.
> https://github.com/vlsi/mat-calcite-plugin
> 
> select * from "java.lang.String" s  produces a row for each String in the
> heap dump.
> 
> Then might be a case like
> select u.path from  "java.net.URL" u;
> That is java.net.URL has "path" field which is of java.lang.String.
> 
> Of course Java classes can produce recursive types, so Node { Node next; }
> bothered me.
> 
> The relevant issue is https://issues.apache.org/jira/browse/CALCITE-207
> 
> I have asked once if RelDataTypeProxy is welcome in Calcite (
> https://issues.apache.org/jira/browse/CALCITE-207?focusedCommentId=14035245&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14035245
> ), however it looks like I have to implement it and see what breaks.
> 
> The idea there was to use RelDataTypeProxy("Node") as a type for the "next"
> field. That should avoid "stackoverflow" on cyclic dependencies in types.
> I would love to know your opinion on that if you happen to have one.
> 
> It's great that you update executor to support nested structs.
> 
> PS. I've not had a chance to review it.
> 
> Vladimir

Reply via email to