GitHub user goutamadwant added a comment to the discussion: DBC Driver returns missing COLUMN_SIZE in DatabaseMetaData.getColumns() for VARCHAR columns mapped from Spark/Hive STRING
The Spark-engine path currently produces exactly that combination. [`SchemaHelper`](https://github.com/apache/kyuubi/blob/d956b252bb1869dbe9d5d45c38e25e0106dcaf93/externals/kyuubi-spark-sql-engine/src/main/scala/org/apache/kyuubi/engine/spark/schema/SchemaHelper.scala#L102-L146) maps `StringType` to `Types.VARCHAR`, but `getColumnSize(StringType)` falls through to `None`. [`SparkCatalogUtils.toColumnResult`](https://github.com/apache/kyuubi/blob/d956b252bb1869dbe9d5d45c38e25e0106dcaf93/externals/kyuubi-spark-sql-engine/src/main/scala/org/apache/kyuubi/engine/spark/util/SparkCatalogUtils.scala#L370-L401) turns that into SQL NULL for `COLUMN_SIZE`. So for this path, the missing value originates in the **engine's metadata result**, not a JDBC-driver length setting. `KyuubiDatabaseMetaData.getColumns()` requests that result from the server. Changing only query-result `getPrecision()` would not repair this `getColumns()` path. An `Integer.MAX_VALUE` convention for unbounded strings seems reasonable to evaluate for interoperability, but it should be string-specific—not a blanket replacement for every unknown size, including arrays/maps/binary values. I'd also verify that the receiving Trino connector maps that convention to unbounded VARCHAR rather than allocating based on it. A useful regression case is a Spark table with one `STRING` column, asserting both `DATA_TYPE` and `getObject("COLUMN_SIZE")` through JDBC. Using `getObject` avoids mistaking `getInt`'s zero-for-NULL behavior for an actual zero length. This confirms the current Spark path; which Kyuubi/engine versions and Trino connector are you using? GitHub link: https://github.com/apache/kyuubi/discussions/7629#discussioncomment-18325623 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
