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:

• [ ] https://github.com/rusqlite/rusqlite/pull/1532/: does this mean that default transaction behavior can interfer with the migrations?
• [ ] Update tokio-rusqlite, once a new version is ready: https://github.com/programatik29/tokio-rusqlite/pull/34
• [X] Update Changelog to prepare for the release #182
• [X] Bump MSRV if needed and see if that unlocks other deps update (#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: https://github.com/programatik29/tokio-rusqlite/pull/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: https://github.com/programatik29/tokio-rusqlite/pull/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 40462f1aaf903f06a25b561d6112b92b9c9f45f0 on rusqlite-033 into bdf4a028e805f159d950e1e99c3c4789568a8c9f 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.