Hi Alessandro, >From what I understand ColumnMetaData mainly exists to provide the necessary information required to satisfy the API of ResultSetMetaData. As far as I can see the ResultSetMetaData does not provide the possibility to obtain information about nested struct fields (only top-level columns) so I guess the current implementation of ColumnMetaData is sufficient to satisfy these requirements. I can imagine that having additional information about nested fields would be useful for some clients other than ResultSetMetaData so I would say that it would be nice to have it.
Best, Stamatis On Tue, Nov 5, 2019 at 2:12 PM Alessandro Solimando < [email protected]> wrote: > Hello, > I noticed that type information inside the "name" field into > "ColumnMetaData" are dropped for the inner components of STRUCT, while they > are preserved for MULTISET, ARRAY, LIST, MAP. > > For example the following "RelRecordType": > > > RecordType( > > INTEGER f_int, > > INTEGER NOT NULL ARRAY f_list_1, > > (VARCHAR NOT NULL, VARCHAR NOT NULL) MAP f_map_1, > > DOUBLE NOT NULL MULTISET f_set, > > RecordType( > > BIGINT f_tuple_1_0, > > VARBINARY f_tuple_1_1, > > TIMESTAMP(0) f_tuple_1_2 > > ) f_tuple_1 > > ) NOT NULL > > > is "translated" into the following when printing the elements of > "ResultSetMetaData": > > > [f_int INTEGER, > > f_list_1 INTEGER ARRAY, > > f_map_1 (VARCHAR, VARCHAR) MAP > > f_set DOUBLE MULTISET, > > f_tuple_1 STRUCT] > > > while I was expecting something like: > > > [f_int INTEGER, > > f_list_1 INTEGER ARRAY, > > f_map_1 (VARCHAR, VARCHAR) MAP > > f_set DOUBLE MULTISET, > > f_tuple_1 (BIGINT, VARBINARY, TIMESTAMP) STRUCT] > > > The difference comes from > "*org.apache.calcite.avatica.ColumnMetaData", *where you > have*:* > > > public static StructType struct(List<ColumnMetaData> columns); > > public static ArrayType array(AvaticaType componentType, String typeName, > > Rep rep); > > public static ScalarType scalar(int type, String typeName, Rep rep); > > > For struct you don't pass "typeName", and the type name is set to "STRUCT" > inside the constructor. > > For uniformity I'd build the type name (inside the aforementioned "struct" > method) similarly to the other "collections", that is: "(columnTypeName_1, > ..., columnTypeName_n) STRUCT". > For this aim, the information inside the parameter "List<ColumnMetaData> > columns" suffices. > > What do you think? Is there any reason I am missing for this different > treatment of collections? > > Best regards, > Alessandro >
