chore! Update rusqlite to v0.33

[cljoly]

This PR aims to introduce a long term solution to update rusqlite to v0.33. If you need an updated version now, there is a stopgap alpha version that you might be able to use.

---

Changelog at https://github.com/rusqlite/rusqlite/releases/tag/v0.32.0

Concerns:

• Allow setting default connection transaction behavior rusqlite/rusqlite#1532: does this mean that
  default transaction behavior can interfer with the migrations?
  • Yes, but I don’t think it matters, because all behaviors can work. Presumably, if someone uses a particular behaviors, they want it to apply also for migrations.
• Update tokio-rusqlite, once a new version is ready: Update rusqlite requirement from 0.31 to 0.32 programatik29/tokio-rusqlite#34
• Update Changelog to prepare for the release Prepare an alpha version without tokio features #182
• Bump MSRV if needed and see if that unlocks other deps update (chore(deps): bump env_logger from 0.10.1 to 0.11.1 #138)

[xuxiaocheng0201]

Hello, is there any progress?

[cljoly]

@xuxiaocheng0201 as I understand it, we need tokio-rusqlite to update first, because we can only link to one version of libsqlite3-sys. You are welcome to open an issue with tokio-rusqlite (I’ll do it when I have more time) or propose a PR to update the dependency in rusqlite_migration if there is a solution I’m missing.

[czocher]

@xuxiaocheng0201 there's already a PR available, waiting for merge: programatik29/tokio-rusqlite#34

[xuxiaocheng0201]

Perhaps we can release a lite version without alpha-async-tokio-rusqlite feature?
It seems that we are unable to contact the author of tokio-rusqlite.
If you have this plan, then I am willing to submit a PR on a new branch.

[cljoly]

Perhaps we can release a lite version without alpha-async-tokio-rusqlite feature?

Yes, we can release an alpha version without the feature, as a stop gap. We will need a more long term solution to release a stable version (where we have compatibility guarantees and try to make things that work well).

If you have this plan, then I am willing to submit a PR on a new branch.

Thanks, please go ahead.

As a side note, I tried dependency renaming (rusqlite_032 and rusqlite_033) to make the default and async features use different dependencies, but we still have the two sqlite versions in the dependency tree and compilation fails.

[czocher]

@cljoly great success, the update was merged: programatik29/tokio-rusqlite#34 we can now update our version.

[cljoly]

Thanks for flagging @czocher!

I understand we are still awaiting a release of tokio-rusqlite, aren’t we?

[coveralls]

coverage: 94.03%. remained the same
when pulling 40462f1 on rusqlite-033
into bdf4a02 on master.

[oxalica]

It seems that no library code is changed to use the new rusqlite dependency. Could we just relax the version specification to allow both rusqlite versions by [rusqlite] version = ">=0.31.0, <0.33"?
I did a quite test, it is both compatible with rusqlite 0.32 when alpha-async-tokio-rusqlite disabled and compatible with rusqlite 0.31 when enabled. So downstream user can decide which way to go and we won't need to wait for tokio-rusqlite (plus we don't need to do anything once they release. Cargo will select the newer version if possible automatically).

[cljoly]

It seems that no library code is changed to use the new rusqlite dependency. Could we just relax the version specification to allow both rusqlite versions by [rusqlite] version = ">=0.31.0, <0.33"?
I did a quite test, it is both compatible with rusqlite 0.32 when alpha-async-tokio-rusqlite disabled and compatible with rusqlite 0.31 when enabled. So downstream user can decide which way to go and we won't need to wait for tokio-rusqlite (plus we don't need to do anything once they release. Cargo will select the newer version if possible automatically).

That's a great idea, certainly worth a try. Please feel free to open a PR. Otherwise I'll try it when I get the chance.