Problem: PgHasArrayType was checking the application's postgres feature
Solution: only check the library's postgres feature
Co-authored-by: Daniel Tashjian <daniel@ecomedes.com>
Given a generic type like `A<B>` before `sqlx` would produce
`A<B>::from_row(row)` which is invalid syntax.
Now it produces `<A<B> as ::sqlx::FromRow<'a, R>>`.
This also fixes a bug for non-generic types where an inherent method
might have been called instead of the `::sqlx::FromRow::from_row` method
because UFCS wasn't used.
* Separate offline query metadata per crate
* Update sqlx-cli prepare to use separate query metadata per crate
* Add resolve.root to metadata test fixture
* Simplify root package resolution
* Fix prepare --merged
When the `#[sqlx::test]` macro is imported using `#[macro_use]` such as
in the following example:
```rust
extern crate sqlx;
mod tests {
#[test]
fn something() {}
}
```
then the `#[test]` generated by the macro will refer to itself instead
of the standard Rust `#[test]` macro. This will cause `rustc` to
recursively expand it and produce the following error message:
```
thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
```
Instead, we can just refer to the standard macro by using its fully
qualified path.
This PR:
* Swaps `#[test]` usages in `#[sqlx::test]` for their hygenic path to
prevent recursive expansion alongside `#[macro_use]`
Closes#2017.
* use direct blocking calls for SQLite in `sqlx_macros`
* this also ensures the database is closed properly, cleaning up tempfiles
* don't send `PRAGMA journal_mode` unless set
* this previously defaulted to WAL mode which is a permanent setting
on databases which doesn't necessarily apply to all use-cases
* changing into or out of WAL mode acquires an exclusive lock on the database
that can't be waited on by `sqlite3_busy_timeout()`
* for consistency, `sqlx-cli` commands that create databases will still
create SQLite databases in WAL mode; added a flag to disable this.
* in general, don't send `PRAGMA`s unless different than default
* we were sending a bunch of `PRAGMA`s with their default values just to enforce
an execution order on them, but we can also do this by inserting empty slots
for their keys into the `IndexMap`
* add error code to `SqliteError` printout
* document why `u64` is not supported
* refactor: Reuse a cached connection instead of always recreating for `sqlx-macros`
* fix: Fix type inference issue when no database features used
* refactor: Switch cached db conn to an `AnyConnection`
* fix: Fix invalid variant name only exposed with features
* fix: Tweak connection options for SQLite with `sqlx-macros`
* fix: Remove read only option for SQLite connection
* fix: Fix feature flags regarding usage of `sqlx_core::any`
* postgres: use Oid type instead of u32
* Make serde happy
* Expose the inner u32
* docs
* Try to fix tests
* Fix unit tests
* Fix order
* Not sure what happened here
* fix(cli): change new `rustls` and `native-tls` features to use correct runtime feature
* chore: upgrade SQLx crates to 0.5.10, upgrade all dependencies to latest versions
chore(cli): upgraded `clap` to `3.0.0-rc.9`
* fix(tests/sqlite): ignore `issue_1467()` as spuriously failing
I'm well aware of the principle that a spuriously failing test is a failing test, but even though I have it outputting the seed used with a reproducible PRNG, I can't reproduce the failures locally, so 🤷.
* chore: add CHANGELOG entry for 0.5.10
In particular building with bazel and cargo-raze doesn't imply having
cargo at all, and deferring the lookup allows same-crate builds to
succeed with no change to semantics.
Fixes#1414
Signed-off-by: Robert Collins <robert.collins@cognite.com>
* fix(macros): tell the compiler about external files/env vars to watch
closes#663closes#681
* feat(cli): add `migrate` subcommand for generating a build script
suggest embedding migrations on `sqlx migrate add` in a new project
