vertx-jooq
vertx-jooq copied to clipboard
jklingsporn
JDBC
Why the JDBC version doesn't use https://vertx.io/docs/vertx-jdbc-client/java/ ?
Yes, this seems to be interesting. Have you done it in the 3x or 4x branch?
2018-04-13 10:58 GMT+02:00 Quentin Desramé [email protected]:
@jklingsporn https://github.com/jklingsporn I made modules to use the (Vertx JDBC Driver)[https://vertx.io/docs/vertx-jdbc-client/java/] Does it interest you ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jklingsporn/vertx-jooq/issues/50#issuecomment-381071694, or mute the thread https://github.com/notifications/unsubscribe-auth/AGC83hrQjOVCUvZPpBLO3RUU-N7IB908ks5toGi6gaJpZM4TKR_g .
-- Jens Klingsporn Beselerstraße 33 22607 Hamburg Tel: 0151/70102082
I made this in 4x branch. Currently, it only works for in classic mode and i call it vertx-jooq-classic-jdbc2 to keep your existing jdbc module. But the development to make it compatible to rx and completable future should be fast.
That's cool. But in order to add it, could you also provide modules for rx and completablefuture module?
2018-04-13 11:43 GMT+02:00 Quentin Desramé [email protected]:
I made this in 4x branch. Currently, it only works for in classic mode and i call it vertx-jooq-classic-jdbc2 to keep your existing jdbc module. But the development to make it compatible to rx and completable future should be fast.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jklingsporn/vertx-jooq/issues/50#issuecomment-381083575, or mute the thread https://github.com/notifications/unsubscribe-auth/AGC83g4kHRPO50ltDuXhLhiHVOrl1Oy-ks5toHMxgaJpZM4TKR_g .
-- Jens Klingsporn Beselerstraße 33 22607 Hamburg Tel: 0151/70102082
Before you continue: what is the benefit of using this driver over the existing -jdbc module? Because from what I understand, it also wraps the query execution in a executeBlocking-block ( https://github.com/vert-x3/vertx-jdbc-client/blob/master/src/main/java/io/vertx/ext/jdbc/impl/actions/AbstractJDBCAction.java). This is the same that -jdbc modules do already.
2018-04-13 11:46 GMT+02:00 Quentin Desramé [email protected]:
Yes i will do it. So should i call it jdbc2 ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jklingsporn/vertx-jooq/issues/50#issuecomment-381084519, or mute the thread https://github.com/notifications/unsubscribe-auth/AGC83p3BeelLjbCW-b6dEjOIfs8PH1f4ks5toHQLgaJpZM4TKR_g .
-- Jens Klingsporn Beselerstraße 33 22607 Hamburg Tel: 0151/70102082
The main interest is that you only have jooq to create SQL like in your others modules. And you can use vertx-jdbc outside of your lib if you have custom use case. Also your driver configuration will be the same.
The main interest is that you only have jooq to create SQL like in your others modules.
That is true. But I'm not sure if this justifies a new module. Then, I'd rather consider switching the existing module to use vertx-jdbc. However the biggest plus of the current jdbc modules is, that you can execute any jOOQ-SQL using executeAny in the JDBCQueryExecutor.
And you can use vertx-jdbc outside of your lib if you have custom use case.
I don't fully understand what you mean by this.
Also your driver configuration will be the same.
Compared to what?
Ok. I can replace your current module in next version.
And you can use vertx-jdbc outside of your lib if you have custom use case.
Yes you can use executeAnyin the JDBCQueryExecutor but i was saying that you can access the native API of vertx-jdbc driver.
Also your driver configuration will be the same.
The driver configuration will be coherent to vertx-mysql-postgresql-client library and global vertx configurations. Also, a lot of code can be factorised with vertx-mysql-postgresql-client because they share the same api from vertx-sql-common.
How would you do something like this (which is possible with executeAny) in the new Client:
dslContext.selectFrom(someTable).fetchSet(someField) (which returns a Set<someFieldType>)?
I pretty sure you can't, because you either have to use the QueryResult - API or the driver specific API (the one that converts all results to JsonObjects for async driver and to Row for reactive driver).
I totally get your point of having one coherent approach to configure vertx-jooq.
What we maybe could do, is separate the functionality of the JDBCQueryExecutor from the existing implementations (that are used by the DAOs) and give the user the chance to instantiate them separately (only having this executeAny method) if they want to follow the jOOQ Configuration-first approach.
What do you think?
So basically, replace vertx-jooq-jdbc with the vertx-jdbc driver as you suggested but have extra implementations of JDBCQueryExecutor for each API to allow execution of arbitrary SQL (using regular JDBC) if the user wants that functionality.
How would you do something like this (which is possible with executeAny) in the new Client:
Yes, you have to use query which returns a QueryResult
What we maybe could do, is separate the functionality of the JDBCQueryExecutor... What do you think?
Yes it's a good idea.
So basically, replace vertx-jooq-jdbc with the vertx-jdbc driver as you suggested but have extra implementations of JDBCQueryExecutor for each API to allow execution of arbitrary SQL (using regular JDBC) if the user wants that functionality.
Yes, that sounds good !
Any update on this? If possible, I'd like to have this part of 4.0-Final release.
@quen2404 Hi. Have you proceeded on this yet? I am also searching for such an implementation as the codebase in my firm extensively uses the driver.
