Thanks all for your answers.
I still have one question / clarification regarding semantics of select *
for document databases (with declared schema).
Say I have the following type definition:
CREATE TYPE mytype AS (
a varchar(2) not null,
b varchar(2) NULL // optional (null?)
);
If my document has only a present ({ a:value }) what should select * return
? Map with single value ({a:value}) or a pair (value, null)
In other words should select * return raw document (as generic map) or list
of mytype ?
If later, how to differentiate between missing attribute (field) and
attribute having null value ?
On Sat, Aug 11, 2018 at 2:51 PM Julian Hyde <[email protected]> wrote:
> 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 <
> [email protected]> 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
>
>
