j1wonpark commented on code in PR #56688:
URL: https://github.com/apache/spark/pull/56688#discussion_r3457267298
##########
sql/connect/client/jdbc/src/main/scala/org/apache/spark/sql/connect/client/jdbc/SparkConnectDatabaseMetaData.scala:
##########
@@ -598,14 +598,51 @@ class SparkConnectDatabaseMetaData(conn:
SparkConnectConnection) extends Databas
catalog: String, schema: String, table: String): ResultSet =
throw new SQLFeatureNotSupportedException
- override def getPrimaryKeys(catalog: String, schema: String, table: String):
ResultSet =
- throw new SQLFeatureNotSupportedException
+ // Spark has no primary keys, so return an empty result set with the JDBC
schema
Review Comment:
You're right, thanks — Spark supports informational PRIMARY KEY / FOREIGN
KEY constraints on DSv2 tables since 4.1 (SPARK-51207). I've corrected the
inaccurate comment.
I looked into returning the real constraints here, but the Spark Connect
JDBC client has no structured way to read them today: the Connect Catalog
API/proto doesn't carry constraints, so the only client-reachable source is
parsing the text output of `DESCRIBE TABLE EXTENDED`. That couples the driver
to a human-readable format, which feels too fragile to land. So I've kept the
empty `ResultSet` here (with an accurate comment), and I think returning real
PK/FK is better done once constraints can be exposed over Connect in a
structured way (e.g. a proto addition), as a follow-up.
Does that sound reasonable, or would you prefer a different approach?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
