Skip to content
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

Update odbc-api requirement from 9.0.0 to 10.0.0 #186

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dependabot[bot]
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Nov 25, 2024

Updates the requirements on odbc-api to permit the latest version.

Release notes

Sourced from odbc-api's releases.

odbc-api-v10.0.0

Added

  • [breaking] odbc-api will now use narrow function calls by default on non-windows systems. This assumes that the ODBC driver on that platform uses UTF-8 encoding. This is usually the case as many Linux systems use an UTF-8 locale. Outside of windows the wide function calls are usually less battle tested on drivers. Downstream artefacts like arrow-odbc and odbc2parquet therefore have been compiling with the narrow flag on non-windows systems for quite a while now to opt into the behavior which most likely works by default. However if somebody had a non-windows platform with a non-utf 8 local and a driver which actually could use UTF-16, he could not set appropriate compiler flags to revert the narrow feature added by these crates. Since the default behavior for each platform is now triggered by odbc-api itself, downstream artefacts can overwrite it both ways. E.g. using the narrow flag on windows to get some speed, if they know their target platform has a UTF-8 local configured. Or the other way around using the wide flag on a Linux system to e.g. handle special character in column names, which only seem to work with the wide variants of the drivers. So if you used odbc-api previously on Linux without any flags it did by default use the wide function calls. It now uses the narrow ones by default. If you want the old behavior just specify the wide feature flag. For windows users nothing breaks.

Other

  • (deps) bump thiserror from 2.0.0 to 2.0.3
  • (deps) bump csv from 1.3.0 to 1.3.1
  • (deps) bump tempfile from 3.13.0 to 3.14.0
  • (deps) bump tokio from 1.41.0 to 1.41.1
  • (deps) bump thiserror from 1.0.68 to 2.0.0
  • (deps) bump anyhow from 1.0.92 to 1.0.93
  • (deps) bump thiserror from 1.0.66 to 1.0.68
  • (deps) bump thiserror from 1.0.65 to 1.0.66
  • (deps) bump anyhow from 1.0.91 to 1.0.92
  • (deps) bump syn from 2.0.87 to 2.0.89
  • (deps) bump syn from 2.0.86 to 2.0.87
  • (deps) bump syn from 2.0.85 to 2.0.86
Changelog

Sourced from odbc-api's changelog.

10.0.0 - 2024-11-24

Added

  • [breaking] odbc-api will now use narrow function calls by default on non-windows systems. This assumes that the ODBC driver on that platform uses UTF-8 encoding. This is usually the case as many Linux systems use an UTF-8 locale. Outside of windows the wide function calls are usually less battle tested on drivers. Downstream artefacts like arrow-odbc and odbc2parquet therefore have been compiling with the narrow flag on non-windows systems for quite a while now to opt into the behavior which most likely works by default. However if somebody had a non-windows platform with a non-utf 8 local and a driver which actually could use UTF-16, he could not set appropriate compiler flags to revert the narrow feature added by these crates. Since the default behavior for each platform is now triggered by odbc-api itself, downstream artefacts can overwrite it both ways. E.g. using the narrow flag on windows to get some speed, if they know their target platform has a UTF-8 local configured. Or the other way around using the wide flag on a Linux system to e.g. handle special character in column names, which only seem to work with the wide variants of the drivers. So if you used odbc-api previously on Linux without any flags it did by default use the wide function calls. It now uses the narrow ones by default. If you want the old behavior just specify the wide feature flag. For windows users nothing breaks.

Other

  • (deps) bump thiserror from 2.0.0 to 2.0.3
  • (deps) bump csv from 1.3.0 to 1.3.1
  • (deps) bump tempfile from 3.13.0 to 3.14.0
  • (deps) bump tokio from 1.41.0 to 1.41.1
  • (deps) bump thiserror from 1.0.68 to 2.0.0
  • (deps) bump anyhow from 1.0.92 to 1.0.93
  • (deps) bump thiserror from 1.0.66 to 1.0.68
  • (deps) bump thiserror from 1.0.65 to 1.0.66
  • (deps) bump anyhow from 1.0.91 to 1.0.92
  • (deps) bump syn from 2.0.87 to 2.0.89
  • (deps) bump syn from 2.0.86 to 2.0.87
  • (deps) bump syn from 2.0.85 to 2.0.86

9.0.0

  • ConcurrentBlockCursor is now generic over the buffer type

8.1.4

  • Fix failed release 8.1.3 due to out of sync version for derive package

8.1.3

  • Fix: Failed attempts to rollback transactions during Drop of a connection will no longer panic.

8.1.2

  • Fix: Connection::execute_polling did not enable asynchronus execution on the statement handle. This means that the operations on that cursor were actually blocking even if the driver does support polling.

8.1.1

  • Fix release. Release from main branch

8.1.0

  • ConnectionAndError now implements std::error::Error.

8.0.1-2

  • Fix: Fix version of odbc-api-derive crate

8.0.0

... (truncated)

Commits
  • 564606b docs: wide feature flag in changelog explained
  • dabd7e8 chore: release
  • 8ffcaff chore: Update release-plz to use plain tag without prefix
  • 3e6b329 feat!: Introduce wide feature flag. Use narrow function calls by default on n...
  • c329a84 chore: update release-plz configuration, to better merge changelogs.
  • e5a0737 chore: use common changelog for workspace
  • 8862dec chore: Introduce release-plz
  • 74ed0c1 chore: Rename changelog to uppercase
  • ed6dd40 chore(deps): bump syn from 2.0.87 to 2.0.89
  • 189f404 chore(deps): bump thiserror from 2.0.0 to 2.0.3
  • Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Updates the requirements on [odbc-api](https://github.com/pacman82/odbc-api) to permit the latest version.
- [Release notes](https://github.com/pacman82/odbc-api/releases)
- [Changelog](https://github.com/pacman82/odbc-api/blob/main/CHANGELOG.md)
- [Commits](pacman82/odbc-api@v9.0.0...v10.0.0)

---
updated-dependencies:
- dependency-name: odbc-api
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot bot added the dependencies Pull requests that update a dependency file label Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants