replace the driver as it is not maintained anymore

[oshai]

mauricio driver is not supported anymore. We created a clone of it in kotlin: https://github.com/jasync-sql/jasync-sql. will you consider using it instead? I can create a PR if you would like.

[vietj]

we will rather adop the reactive postgres client in vertx 4.0

unfortunately it does not support mysql, perhaps you can rather contribute there ?

[vietj]

for the record : https://reactiverse.io/reactive-pg-client/

[oshai]

Yes I can contribute the mysql part as well. How should I do that?

[vietj]

I think forking the reactive-pg-client and replacing the internal postgres parts by mysql would be the best, at least for the basic interactions (connection , query)

After this step we will have a pretty good idea of what is different and we can refactor the pg client to be not couppled to PG and use either postgres or mysql protocol.

[vietj]

if you are going this way, let me know and I'll subscribe to your fork for following and discussing.

[oshai]

I don't think that the suggestion is practical. It also couples the driver to vertex if I understand correctly. What about forking this repo and adapting? What is the downside?

[vietj]

why isn't it practical ?

[oshai]

There are a lot of features that are missing/different: notifications, cursor, streams, rx support etc'.

[vietj]

ah ok... I mean the idea is to not implement it completely but just start implementing basic (so other will throw UnsupportedOperationException).

The idea is that once basic interactions are implemented then I can use this to refactor the PG client and start introduce an SPI for PG and MySQL, so the core of the client can be used for both.

The current simplified architecture looks like:

PG API -> PG Connection management -> PG Commands

And I would like to go in the MySQL fork:

PG API -> MySQL Connection management -> MySQL Commands

Which would lead to the refactoring:

PG API -> Connection management -> (PG|MySQL) Commands

And then we figure out something such as the PG specific things are decoupled from the PG API.

I think the most important part in there is the middle layer Connection management that I would like to remain the same for all databases.

The API is just a front end to trigger commands at the end of the day.

I hope this makes sense.

[oshai]

@vietj - here is an example of how to convert this lib to jasync-sql: https://github.com/vert-x3/vertx-mysql-postgresql-client/pull/126 if you prefer I can try to go the way you suggested, it might require more work.

[vietj]

@oshai on the middle term we want to support support the reactive-pg-client as it provides also a better API for interacting with database than the SQLConnection. We decided also to deprecate this project in 4.0 . So your contribution would have a greater impact on the project.

[oshai]

I forked the repo: https://github.com/oshai/reactive-pg-client and created an initial implementation commit: https://github.com/oshai/reactive-pg-client/commit/1f84bb0d4f9c5493cadab238fdec3021fb3497dd

Let me know what do you think.

[andy-yx-chen]

@oshai thanks for your hard work on jasync-sql, as far as I know jasync-sql is more up-to-dated than the current dependency (Scala one), right? I don't understand why we should not just use jasync-sql instead of current dependency, if this plugin will not take the suggestion, I think we can just for this, port to jasync-sql (I already done), and publish to maven center, waiting for reactive-pg-client is not a good idea to go, as the current dependency is even more sophisticated. In open source world, people will always choose what is better. The only thing I want to point out is keep all hard working and don't let it die again, let's try to see if we can make more developers happier, here is my branch with jasync-sql https://github.com/andy-yx-chen/vertx-mysql-postgresql-client I also have a PR for this repo, but according to this thread, I don't think they are going to accept it, but anyways, I will use jasync-sql in my production, at least it has better support

[vietj]

@andy-yx-chen I think we can consider accepting your PR if you can support it on the mid/long term

[andy-yx-chen]

@andy-yx-chen I think we can consider accepting your PR if you can support it on the mid/long term

Yes, I will keep contributing to both projects, jasync and this project, as we are high rely on reactive frameworks like vertx

[codepitbull]

On first sight I see a ton of good things in this idea. We would get rid of a Scala-dependency (makes my life easier) and we would get a maintained driver. I am just hesitent about the impact this could have to users of the exisiting driver. This is a rather big change and will impact allocation behavior and other areas. I am not trying to qualify these changes, they can be both good and bad but they will be unexpected. So if we want to do this we have to think about how we are goin g to handle it, especially for the future.

First: I talked with Maurico about a fork and he supports this idea. This would help us support this driver until we reache Vert.x 4 for which we planned to actually deprecate it.

Second: This PR and future maintenance is a rather big change and will cause quite some work for @andy-yx-chen .

If we want to switch out the underlying driver then I would do this with a Vert.x 3.7-Release and also reconsider our plan to deprecate the driver and instead keep it as a secondary option.

[andy-yx-chen]

This would help us support this driver until we reache Vert.x 4 for which we planned to actually deprecate it.

That would be great, the motivation for me to drive this is because i already see many open issues regarding to current driver, as a open source community, we should move fast, that's why developers can trust. If the current driver is lacking of support, then we should think about what is the next, either pure java driver (should be at least as stable as current one) or something that is currently widely used. To be honest, I am pretty happy to see @oshai 's work, though it's kotlin, but with support. I already use jasync in our production system because of trust. I am fine with moving this forward with any agreed directions, but again, if we cannot fix some of the pending issues, then we should think about what should be the next

[andy-yx-chen]

@oshai @vietj @codepitbull F.Y.I. though requesting for merge into 3.6 is not a good option, our team keep working on it, now we have implement the connectionTimeout and testTimeout which was removed in previous iteration (thanks @oshai to publish 0.8.55 for a improvement submitted by @bytewayio). I will keep working on it, as we may still need to add another connectionTimeout guard in AsyncConnectionPool, as it will put the request into waiting for more connections or waiting for test query

[vietj]

I concur with you Jochen, you are the lead and should make the call.

my point is that I don't want to prevent somebody in community to step up and contribute.

keep us informed with Mauricio's discussion.

On 11 Dec 2018, at 22:12, Jochen Mader notifications@github.com wrote:

On first sight I see a ton of good things in this idea. We would get rid of a Scala-dependency (makes my life easier) and we would get a maintained driver. I am just hesitent about the impact this could have to users of the exisiting driver. This is a rather big change and will impact allocation behavior and other areas. I am not trying to qualify these changes, they can be both good and bad but they will be unexpected. So if we want to do this we have to think about how we are goin g to handle it, especially for the future.

First: I talked with Maurico about a fork and he supports this idea. This would help us support this driver until we reache Vert.x 4 for which we planned to actually deprecate it.

Second: This PR and future maintenance is a rather big change and will cause quite some work for @andy-yx-chen https://github.com/andy-yx-chen .

If we want to switch out the underlying driver then I would do this with a Vert.x 3.7-Release and also reconsider our plan to deprecate the driver and instead keep it as a secondary option.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/125#issuecomment-446363780, or mute the thread https://github.com/notifications/unsubscribe-auth/AANximvIBhUlg29_1agZ64Nqjfz409dhks5u4B_RgaJpZM4XDjoX.

[codepitbull]

I finally got some time to take a look at the PR. It really looks good and I couldn't find any issues with the implementation.

This still leaves some organisational issues.

I'd suggest to move the Scala-based version into a separate branch and keep it as a backup. We can't be sure that people didn't fiddle with some internals and I don't want to cause too much hamr to them, especially since we are so close to the end of the driver.

I also don't want to release this as a patch update. We won't have API changes but replacing the whole groundworks of the driver is somethign I don't want to hide in a patch.

@vietj already created a 3.6 branch which should continue to contain the Scala driver. I'd suggest to open a 3.7 branch and merge the changes there.

Would that work for everyone?

[andy-yx-chen]

sounds good to me, thanks for reviewing!

[vietj]

@codepitbull could we instead live with the two codebases in the same project and support both in 3.6.x ? that would allow anyone to use the new impl and keep the old one.

if we ever do a 3.7, then we would remove the scala one.

[codepitbull]

@vietj how would we differentiate the two? Something like vertx-mysql-postgresql-client and vertx-mysql-postgresql-client-jasync-sql?

[vietj]

I think both could be in the same jar and the difference would be the static method to create it ?

On 18 Dec 2018, at 09:15, Jochen Mader notifications@github.com wrote:

@vietj https://github.com/vietj how would we differentiate the two? Something like vertx-mysql-postgresql-client and vertx-mysql-postgresql-client-jasync-sql?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/125#issuecomment-448133749, or mute the thread https://github.com/notifications/unsubscribe-auth/AANxiqN0BESEWLUwnBcyLwMZNwVmQeVRks5u6KQTgaJpZM4XDjoX.

[codepitbull]

@vietj I'd like to avoid having the Scala deps dragged into the Kotlin-version and vice versa.

[vietj]

that's a good point, unfortunately maven does not allow to have per classifier dependencies unless we make them both optional.

On 18 Dec 2018, at 10:26, Jochen Mader notifications@github.com wrote:

@vietj https://github.com/vietj I'd like to avoid having the Scala deps dragged into the Kotlin-version and vice versa.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/125#issuecomment-448153662, or mute the thread https://github.com/notifications/unsubscribe-auth/AANxikO58iF9wl8yXir1rpoFbHbp21vYks5u6LSsgaJpZM4XDjoX.

[codepitbull]

Exactly, the only clean way I see is to provide them as separate dependencies. Anthing else will make things very confusing for users.

[vietj]

I agree, we need to convey however that this is the same artifact with a different implementation I guess

On 18 Dec 2018, at 17:05, Jochen Mader notifications@github.com wrote:

Exactly, the only clean way I see is to provide them as separate dependencies. Anthing else will make things very confusing for users.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/125#issuecomment-448273317, or mute the thread https://github.com/notifications/unsubscribe-auth/AANxim_vxtFSWHhfvJuVQFlM5Q23FLNXks5u6RJUgaJpZM4XDjoX.

[andy-yx-chen]

So, what is the decision then? I am planning to enable MySQL 8.0 support as well as batching and fixing Json data issue

[vietj]

I think what @codepitbull said is the answer

[codepitbull]

I'll be working on this as soon as I get time (hopefully this weekend). My plan is to add two submodules to this project:

vertx-mysql-postgresql-client vertx-mysql-postgresql-client-jasync-sql

I'll keep the name of the original module so we don't confuse people. I will sprinkle the original module with deprecation warnings so users know what to do.

[codepitbull]

I am back from family vacation and working on the changes :) Might be a little bumpy until I am done ...

[oshai]

@codepitbull I suggest to use version 0.8.58 as it has some fixes. you can see details here: https://github.com/jasync-sql/jasync-sql/blob/master/CHANGELOG.md

[codepitbull]

PR is currently building, already updated to 0.8.58. Version 0.8.59, which is mentioned in the changelog, is nowhere to be found.

[oshai]

It's the next version. Not published yet.

בתאריך יום ד׳, 2 בינו׳ 2019, 12:47, מאת Jochen Mader < notifications@github.com>:

PR is currently building, already updated to 0.8.58. Version 0.8.59, which is mentioned in the changelog, is nowhere to be found.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/125#issuecomment-450833589, or mute the thread https://github.com/notifications/unsubscribe-auth/ACj0QWR4cDW08sOam_A0PZyT1wyNN2ZYks5u_I5HgaJpZM4XDjoX .

[oshai]

Thanks for adding it.