Kyuubi Frontend & MySql feature status

[yaroslavambrozyak]

Hi, I am looking forward to using Kyuubi Frontend UI & Mysql features, I have checked the master branch and could see a simple UI present, also I was trying to use MySql connector but got some SQL parsing errors.
So I am really interested in both features and I am curious if these features are in development?
Thanks!

[yaooqinn]

Please subscribe to our mailing list https://kyuubi.apache.org/mailing_lists.html to sync with the community, otherwise, you may miss some important decisions https://lists.apache.org/thread/qk5ftp6jd0w37lv018mn4zx75d7m2n0w

[yaroslavambrozyak]

Sure, thanks!

[pan3793]

The current MySQL protocol frontend should work with mysql CLI and JDBC driver, but does not work with GUI tools like DBeaver or some ORM framework, becuase it lacks support for MySQL dialect. We plan to introduce a SQL parser layer to support that case in Q3(maybe).

[yaroslavambrozyak]

thanks, yep, I was asking about GUI tool, I should have mentioned that

[mmuru]

@pan3793:
Using Kyuubi master custom build, MySQL frontend protocol. Query data from Delta lake tables via DBeaver (22.1.3 and JDBC driver 8.0.17).

I was able to perform queries, show tables, describe table etc on DBeaver SQL console but when I tried to view Tables metadata then it throws below exception.

We had a similar issue with viewing delta tables metadata using Hive/Thirft protocol but it got fixed in Kyuubi 1.4 (I think). Just wondering, is it a similar issue with MySQL protocol or still dialect parser issue?

Please, let me know.
Thanks
Muru

Unknown exception: org.apache.kyuubi.KyuubiSQLException: org.apache.kyuubi.KyuubiSQLException: Error operating ExecuteStatement: org.apache.spark.sql.catalyst.parser.ParseException: 
missing 'FUNCTIONS' at 'TABLES'(line 1, pos 58)

== SQL ==
/* ApplicationName=DBeaver 22.1.3 - Metadata */ SHOW FULL TABLES FROM `default`
----------------------------------------------------------^^^

	at org.apache.spark.sql.catalyst.parser.ParseException.withCommand(ParseDriver.scala:266)
	at org.apache.spark.sql.catalyst.parser.AbstractSqlParser.parse(ParseDriver.scala:127)
	at org.apache.spark.sql.execution.SparkSqlParser.parse(SparkSqlParser.scala:51)
	at org.apache.spark.sql.catalyst.parser.AbstractSqlParser.parsePlan(ParseDriver.scala:77)
	at org.apache.spark.sql.SparkSession.$anonfun$sql$2(SparkSession.scala:616)
	at org.apache.spark.sql.catalyst.QueryPlanningTracker.measurePhase(QueryPlanningTracker.scala:111)
	at org.apache.spark.sql.SparkSession.$anonfun$sql$1(SparkSession.scala:616)
	at org.apache.spark.sql.SparkSession.withActive(SparkSession.scala:775)
	at org.apache.spark.sql.SparkSession.sql(SparkSession.scala:613)
	at org.apache.kyuubi.engine.spark.operation.ExecuteStatement.$anonfun$executeStatement$1(ExecuteStatement.scala:94)
	at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
	at org.apache.kyuubi.engine.spark.operation.SparkOperation.withLocalProperties(SparkOperation.scala:87)
	at org.apache.kyuubi.engine.spark.operation.ExecuteStatement.org$apache$kyuubi$engine$spark$operation$ExecuteStatement$$executeStatement(ExecuteStatement.scala:89)

[pan3793]

it's a dialect parser issue