Returning a list of mytype seems preferable. As far as missing vs. null attributes, I think the distinction is commonly not that important and if it is, there should be some method of accessing the raw document as a fallback.
-- Michael Mior [email protected] Le lun. 13 août 2018 à 16:40, Andrei Sereda <[email protected]> a écrit : > 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 > > > > >
