feat!: Add support for r2dbc driver connections #2266
Draft
+4,888
−737
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
- Implement all API interfaces and abstract classes - Extract base logic from Database to new DatabaseApi and implement r2dbc versi> - Add dialect-specific metadata providers and example tests (Oracle and SQl Ser> are mostly not implemented) - Implement custom transaction manager, but need to decide on what to do with transaction (existing blocks).
- Add SqlTypeProvider and PropertyProvider objects to be held by a MetadataProv> instance representative of each supported database. - Add missing KDocs. - Add tests for all metadata queries.
- Add notes about restrictions related to Oracle, SQL Server, and PostgreSQL-NG
…ltApi - Introduce ResultApi interface that wraps actual database result - Introduce JdbcResult and R2dbcResult - Since only getting object by index and/or type is supported by R2DBC, all uses of ResultSet specific getType() functions in source code have been replaced by getObject()
- The test getKeywords() passes locally but occasionally fails on TC build
… plain sql - Set connection url as proprty of R2dbcDatabase so it can be accessed without retrieving metadata - Remove getUrl() from MetadataProvider and subclasses - Introduce Transaction.execQuery() that returns a Flow based on a transformation - Introduce Transaction.execQuery() that executes without transformation - Add unit tests (commented out as conflict between driver dependencies)
…ls to jdbc module - executeQuery(), executeBatch(), and executeMultiple() now suspend, as do many internal or private functions - Transaction.exec() variants should also suspend as they are used frequently, but this is problematic for jdbc and trickling up - Any use of exec() or Statement.execute() in vendor dialects has been moved to jdbc module - Since Statement.execute() is used heavily in Queries.kt, creation of each statement has been extracted to a common StatementBuilder object. That way execution can be separated by introducing suspend variants of insert/update/delete etc. - A decision needs to be made about query statements and SchemaUtils and all other internal uses. - Marked all potential breaking changes and places that may need suspend
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.
Description
Summary of the change: Provide a concise summary of this PR. Describe the changes made in a single sentence or short paragraph.
Detailed description:
Type of Change
Please mark the relevant options with an "X":
Updates/remove existing public API methods:
Affected databases:
Checklist
Related Issues