Port SQLPage to sqlx 0.9 driver crates#1292
Draft
lovasoa wants to merge 9 commits into
Draft
Conversation
This file contains hidden or 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
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.
Port SQLPage to sqlx 0.9 with external SQL Server and ODBC drivers
Summary
This draft PR ports SQLPage away from the
sqlx-oldapicompatibility crate and onto the currentsqlxcrate. SQL Server and ODBC support move to the externalsqlx-sqlserverandsqlx-odbccrates.The important API change is that
sqlx::Anyin sqlx 0.9 no longer preserves the driver-specific row/type information SQLPage needs for JSON conversion, CSV import, DB-backed files, and backend-specific behavior. The implementation therefore replaces SQLPage's centralAnyPoolusage with a small SQLPage-owned backend enum and dispatches to native sqlx pool/connection types.Checklist
sqlx-oldapitosqlx0.9,sqlx-sqlserver, andsqlx-odbc.sqlx::any::AnyKindwith a SQLPage-owned backend kind enum.AnyPoolandPoolConnection<Any>with SQLPage-owned pool and connection enums.NOCASEcollation, and Unicodeupper/lowersupport where supported by the new API.AnyRow.Any.DECIMAL/NUMERICtext-buffer values as JSON numbers instead of strings, including Oracle ODBC's leading-dot decimal formatting.sqlx-sqlservercrate and use the new0.0.3typed decoders for decimal/money, date/time, datetimeoffset, and uniqueidentifier values. No upstream issue needed.sqlx-sqlserver; opened upstream issue Decode SQL Server VARCHAR using column collation/codepage instead of UTF-8 lovasoa/sqlx-sqlserver#1 for non-UTF-8VARCHARdecoding. SQLPage's MSSQL CSV fixture usesNVARCHARliterals and character-code construction for Unicode/quoted text until that is fixed upstream.COPYand using normal inserts for other backends.sqlx-odbcdoes not implement migration support.sqlx-sqlserver/native-tlsand install full Perl in the Docker builder so cross-compiled images can build OpenSSL from source.cargo fmt --all.cargo clippy --all-targets --all-features -- -D warnings.cargo test.Validation
cargo checkcargo fmt --allcargo test sql_to_jsoncargo test --test examplesSQLPAGE_TEST_EXAMPLES_POSTGRES_ADMIN_URL='postgres://root:Password123!@127.0.0.1/postgres' SQLPAGE_TEST_EXAMPLES_MYSQL_ADMIN_URL='mysql://root:Password123!@127.0.0.1/mysql' cargo test --test examplesDATABASE_URL='mysql://root:Password123!@127.0.0.1/sqlpage' cargo test transactions::test_transaction_errorDATABASE_URL='mysql://root:Password123!@127.0.0.1/sqlpage' cargo test sql_test_files::run_all_sql_test_filescargo clippy --all-targets --all-features -- -D warningscargo testdocker build --platform linux/amd64 --build-arg TARGETARCH=amd64 --build-arg BUILDARCH=amd64 --build-arg CARGO_PROFILE=dev --target minimal .progressed past vendored OpenSSL configuration and project compilation after installing full Perl; the finalmvfailed because Cargo's built-indevprofile writes todebug/while the Docker scripts expect the named profile directory used bysuperoptimized.docker compose up -d mssql, but the local arm64/QEMU environment cannot start the amd64 SQL Server image (Invalid mapping of address ... reserved address space). The SQL Server example SQL was still reviewed and corrected to T-SQL.