Stamatis>possibly many objects from various different classes are under a
single table
That is fine. For instance, if class ByteArrayInputStream extends
InputStream, then
select * from instanceof.java.io.InputStream; would produce both instances,
and the types of columns will be limited to the ones of InputStream
ClassLoaders break that (there might be multiple variations of InputStream
class with different fields), however I just ignore that for now.
Stamatis>Furthermore, the way you use the DOT notation in queries it mostly
means a
join rather than field access
That depends. It might make sense to apply query optimizer so it could
decide which one is better.
Stamatis>From a quick look at your project, it seems that this is what you
are doing
so I guess you are not relying on struct types after all.
It is "struct and egg" problem: Calcite lacked structs, so I used whatever
was implemented.
Re proxy types, it looks like "select *" is not defined there.
Consider
Julian> Since Calcite is grounded in SQL, I would encourage people to give
Julian> examples in terms of SQL (DDL, queries, results), not just in terms
of
type ListElement is record (
value int,
next ListElement
);
then one issues "select value, next from table_of_ListElements".
Of course "next" should not load all the chain. At the end of the day, it
could be even self-referencing chain (or a chain with 100500 elements)
So "next" field should behave more like a proxy to the actual data.
1) Validator should expect "next" to have the fields of ListElement, in
other words
"select value, value.next.next.value" should be valid while "select value,
next.abc" should be invalid
2) The contents of "next" should be represented as a "locator" or something
like that. That is at ResultSet processing site it could be something like
Map listElement = (Map) rs.getObject("next"); // <-- issues roundtrip
Map nextElement = (Map) listElement.get("next"); // <-- issues roundtrip
nextElement.get("value"); // <-- issues roundtrip
This approach looks to be statically typed, so it looks feasible to me.
Stamatis>Thus for the moment, I am not sure if the recursive struct
definition is a
must-have feature for Calcite
Of course it is not a must-have.
I just want to reconsider implementation of mat-calcite-plugin to use
structs or something like that so SQL queries can be written in a type-safe
manner.
Vladimir
