You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The sqlite3_libversion() and sqlite3_libversion_number() APIs are now wrapped by public static Swift methods on SQLConnection, making it simpler for clients to find out what version is in use. Provides necessary support for a corresponding update to enable version-specific feature support in vapor/sqlite-kit.
Additional changes:
Dropped support for Swift versions up to and including 5.4; 5.5 is now the minimum.
CI has been heavily updated (current Swift versions, code coverage and API breakage, etc.)
Modernized use of NIO by unit tests.
Allow overriding logging level in tests with LOG_LEVEL env var.
❗ Current head 0ac5d5e differs from pull request most recent head 369674e. Consider uploading reports for the commit 369674e to get more accurate results
The reason will be displayed to describe this comment to others. Learn more.
This looks good overall. Main comment is that there no test to ensure the new API can at least be called. And will be this superseded by #35 if we can just control the version we embed
This looks good overall. Main comment is that there no test to ensure the new API can at least be called. And will be this superseded by #35 if we can just control the version we embed
I thought about adding a test, but the most it could possibly verify is SQLConnection.versionNumber == sqlite3_libversion(), which is so thoroughly redundant as to be pointless. The API still has legitimate use after #35 is merged; we don't want to hardcode things into SQLiteDialect just 'cause we can (especially since users might presumably need to roll back to an earlier SQLiteNIO - for example, due to bugs in a new SQLite release). The API is also desirable to have generally available for clients of this layer to use (i.e. rather than having to import SQLite).
* Drop support for Swift <5.5
* Bring CI up to date
* Modernize NIO usage and add log level override support for unit tests
* Add static methods on SQLiteConnection to make the runtime version of SQLite available to higher layers without having to use SQLite APIs directly.
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.
gwynne
force-pushed
the
version-reporting-support
branch
from
The
sqlite3_libversion()andsqlite3_libversion_number()APIs are now wrapped by public static Swift methods onSQLConnection, making it simpler for clients to find out what version is in use. Provides necessary support for a corresponding update to enable version-specific feature support in vapor/sqlite-kit.Additional changes:
LOG_LEVELenv var.