Allow the Tokio runtime for SQLx #25
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
is this going to merge any soon? |
|
Love this |
|
This would be very helpful. I'm using the CyrusAlbright:main fork and it seems to work well. |
|
+1 for this. My fork also bumps the dependency versions, if you need it |
Iron-E
added a commit
to Iron-E/winvoice-server
that referenced
this pull request
May 27, 2023
This is because I have to implement my own `async-session` store for SQLx, since jbr/async-sqlx-session#25 hasn't been merged for ~2 years and I don't want to wait to keep writing this project.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It looks like recently some changes had been made to move away from async_std in this library, but it still didn't work for me using Tokio because the Cargo.toml only had options for SQLx to be run with async_std. Unfortunately, allowing Tokio means moving to SQLx's features system, which will break backwards compatibility, but it will be worth it to complete the move away from async_std.
The only functional change made here is exposing SQLx's runtime and TLS features combinations to allow for any configuration. In terms of versioning, I just changed it from 0.4.0 to 0.4.1 but since this is not backwards compatible it might be more suitable to change it to 0.5.0. Technically it shouldn't matter much according to semantic versioning because since this is pre-1.0.0 the API isn't considered public and hence anything can be subject to change.
Either way, this change is very minimal, so just a quick yes or no and an explanation should be all. Thanks.