diesel-derive-enum
diesel-derive-enum copied to clipboard
Tests fail unless forced to run on single thread
Hi! In my code I think I have an issue with renaming of nullable enum values, so I figured I try running your tests and maybe extending them. However I didn't get that far, because I get test fails with the tests that are already there.
Is this something to do with my setup? I tried both postgres 9 and 10.
martin@rexlk:~/dev/diesel-derive-enum/tests$ cargo test --features postgres nullable
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running target/debug/deps/tests-4a7899a1fb646353
running 2 tests
test nullable::nullable_enum_round_trip ... FAILED
test nullable::not_nullable_enum_round_trip ... ok
failures:
---- nullable::nullable_enum_round_trip stdout ----
thread 'nullable::nullable_enum_round_trip' panicked at 'called `Result::unwrap()` on an `Err` value: DatabaseError(__Unknown, "column \"my_enum\" is of type my_enum but expression is of type pg_temp_2.my_enum")', src/libcore/result.rs:916:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
failures:
nullable::nullable_enum_round_trip
test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 3 filtered out
Oh wait. It's stranger than that. It's intermittent. Running the tests over and over, sometimes it succeeds.
Could it be that the pg_temp
is not isolated per connection and we get concurrency problems between the two tests?
Hi, yeah there is some kind of problem with isolating the tables in Postgres. I think the problem is that CREATE TYPE ENUM
is not local to the (temporary) schema. Rather than bother to understand it properly I just serialized the tests like RUST_TEST_THREADS=1 cargo test --manifest-path=tests/Cargo.toml --features="postgres"
(see travis.yml). Still inexplicably fails sometimes but much more rarely.
But I would welcome a proper way to do it!
To go into more detail, when we obtain a PgConnection
, we run conn.execute("SET search_path TO pg_temp;").unwrap();
. Now pg_temp
is actually an alias to a temporary schema which by my understanding should be connection-local (see https://dba.stackexchange.com/questions/76494/temporary-schema-per-connection). Then we should be able to create types and tables isolated from other connections.
But, for whatever reason, it just don't work the way I expect.
Exciting stuff. Thanks! My problem was (obviously) not your package, but my code :D
Good to know. I'll keep this issue open to remind myself that the testing setup is an unfortunate hack.