-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
R2DBC support #456
Comments
A pluggable low-level database access layer would be even more better. It would be possible to support more "special" non-standard implementations like https://github.com/reactiverse/reactive-pg-client |
R2DBC support is built best on top of R2DBC SPI directly and not on R2DBC Client. R2DBC is for reactive programming what JDBC is for imperative programming. R2DBC can easily wrap less-capable asynchronous/non-blocking SQL database drivers exposing their functionality through a standardized SPI. Javadoc: https://r2dbc.io/spec/0.8.0.M8/api/ |
Is this in progress? Would love to use Exposed if this was in. |
Any news? :) |
Are there any plan on this? |
Alright its my time to shine. Ahem.
|
Hi everyone, I have a prove of concept implementation of RDBC driver support, BUT! Right now I had decided to add ability to provide optional JDBC connection as a It means that all DML operations will be handled by RDBC driver and all other with JDBC. What do you think about it? |
Brilliant news!!! But here are a couple of things:
|
@WithoutCaps ,
|
@Tapac Are you planning on having people try out the proof of concept? |
@jvisker , yep. Have to add some tests and add documentation on how to use it. Hopefully I'll release it on the next week. |
Did I miss this release somehow? |
Nope, I just stuck with fixing all current tests with R2DBC driver. The tests with savepoints still fail, so I can't release it right now. |
hi @Tapac - any news here? |
Any updates? |
Is there an estimated completion date for this issue? |
Hi @Tapac There is no update on this issue for a long time. Last information that we get about progress was in August 2020. Could you please tell us whether this issue still on development or not? |
Nice work @Tapac! When do you think this can be considered production ready? I am asking for Postgres specifically. |
The last commit seems to be 9 months ago. For this reason, I guess that this task will not be released in the near future, and its development is not continuing at the moment. I wish there was an estimated time. |
What needs to be done for this to be production ready? |
Not involved with the R2DBC project at all, but it looks like the R2DBC guys are waiting for expressed interest before implementing a DB introspection mechanism. For people that want to see this happen, I suggest upvoting r2dbc/r2dbc-spi#203 . @Tapac In the interim, would you accept a PR if someone continued the work of doing DB specific introspection for the places where it's needed or were you intending to resume this effort sooner than later? |
For now now I have uncompleted branch with R2DBC support with JDBC used for data introspection. After recent updates in R2DBC API with tests doesn't pass and I'm not have enough time to debug the problem. |
No problem, this is more of a wishlist item than a core feature I'd say and it's initial implementation will still be a blocking implementation that has to live in it's own threads for the time being. I took a stab at trying to update the framework to use suspend calls throughout but that is gonna be a downright massive effort. There are many places where properties are delegated by lazy to blocking calls and those would have to all be changed to suspend functions like from the metadata calls on Database. Lots and lots of refactoring. You also have the issue that converting much of the framework to suspend invocations will make it backwards incompatible. If you have a plan though and can think of a way to break it down into individual efforts, I and others might have time to help you convert portions of it all to suspendable invocations so that eventually the framework is suspendable enough to share main worker threads in reactive frameworks like ktor and vertx. |
any updates? |
I got a wife and 2 beautiful children |
Code before family! 🥺 ❤️ |
Is there an estimated completion time of this issue? I apologize for asking this so many times. but we are at the point of switching to alternative solutions, even though I am very satisfied with exposed. |
Hi @Tapac |
@Tapac asking again |
For me, this is - unfortunately - a reason to say goodbye to Exposed in favor of jOOQ which comes with coroutine support |
I encourage you and everyone else to give vertx.io a try; it is the best thing that JVM ecosystem has to offer. |
https://github.com/komapper/komapper is another alternative that is quite similar to Exposed to use and comes with both JDBC and R2DBC support |
As JetBrains recently had a job posting for Exposed, I still haven't lost all my hope that this project will be resurrected and features like this finally tackled. Might take another two years though... |
Happy 5th birthday to this issue 🎉 |
Recently, is this issue working on? I can't wait any more. |
we use jooq, which works fine with r2dbc |
@hohohokekeke According to their most recent talk on Exploring the Exposed Library A Kotlin Solution to Database Access | Chantal Loncle, yes, this is in progress and part of the 2024 roadmap (but I assume that doesn't necessarily mean it will be released this year, just that it's in progress). |
Kotysa is also a good alternative |
Please make it possible to use https://github.com/r2dbc/r2dbc-client
The text was updated successfully, but these errors were encountered: