bobbai00 commented on issue #4393:
URL: https://github.com/apache/texera/issues/4393#issuecomment-4270587584
I looked into this a bit. There seem to be 2 reasonable choices for us:
The first would be to swap `mysql-connector-java` for an Apache-2.0
licensed MySQL client, such as the Vert.x MySQL Client
(`io.vertx:vertx-mysql-client`) or the asyncer fork of r2dbc-mysql
(`io.asyncer:r2dbc-mysql`). But neither uses JDBC — they're reactive clients —
so adopting either would mean rewriting `MySQLSourceOperator` against a
different API.
The second option is to keep the JDBC-based implementation but stop
bundling the driver. JDBC itself is just a set of interfaces in the JDK
(`java.sql.*`) and carries no license concerns; only the `mysql-connector-java`
jar does. This is the approach Calcite and Flink take: they compile against the
JDBC API, load the driver
dynamically at runtime, and leave it to the user to supply the jar.
Concretely, on our side we'd remove the dependency from the binary distribution
and replace any static reference to the driver class with a dynamic load, e.g.
`Class.forName("com.mysql.cj.jdbc.Driver")` before opening a connection. On the
user side, they would download
`mysql-connector-j-x.x.x.jar` from MySQL themselves and drop it into
Texera's classpath — for example into a `lib/` folder that gets picked up at
startup, or by setting `-cp` when launching. We'd document this in the MySQL
operator's README.
Which way do you think we should go with? @Yicong-Huang @chenlica
@aglinxinyuan @Xiao-zhen-Liu
--
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]
