Example and step-by-step explanation added for composite-types in PostgreSQL #3855
Conversation
|
I feel like for more experienced readers this would benefit from a: TLDR; when CREATE TYPE gray_type AS (intensity FLOAT4, suggestion TEXT);then Record<(f32, String)>or #[derive(Debug, FromSqlRow)]
pub struct GrayType {
pub intensity: f32,
pub suggestion: String,
}
impl FromSql<PgGrayType, Pg> for GrayType {
fn from_sql(bytes: PgValue) -> deserialize::Result<Self> {
let (intensity, suggestion) = FromSql::<Record<(Float, Text)>, Pg>::from_sql(bytes)?;
Ok(GrayType {
intensity,
suggestion,
})
}
} |
I immediately agree that I'm a novice: I wrote this manual here to explain what happened, so for an expert it is certainly verbose. But frequently people struggle with understanding it, given the logs on the Diesel matrix channel. Possibly this description could integrate better with the current documentation, but I've no idea where to start. |
Oh I just mean that I think it would be nice to have a TL;DR section at the top of the guide, not suggesting any other particular change. |
|
I tried to include your suggestion, but while doing so, I see you wrote: while you actually meant this, I assume: This is exactly the reason why I wrote to the manual: to be sure that I (and the reader) understand which types should be used where or at least have a working example to play with. For an experienced eye this may be an obvious error, but as a novice you end up in trial and error any combination of types, until you give up :-( |
The sql_query commands on lines 334 and 372 can be executes in parallel during a test and create a failure. With locking the users table this is avoided.
|
Ah I thought I had answered this but apparently I didn't submit, sorry.
Yes absolutely.
I agree it's really nice to have a manual. It's just that while reading it I felt like it was clear but rather long to read if you already know most of what you want to know, so I felt that it would benefit from a "summary" section (a.k.a. TL;DR) that would just give a quick example of just what types you need. |
diesel_tests/tests/update.rs
Outdated
| @@ -369,7 +370,8 @@ fn upsert_with_sql_literal_for_target_with_condition() { | |||
| let connection = &mut connection(); | |||
| // This index needs to happen before the insert or we'll get a deadlock | |||
| // with any transactions that are trying to get the row lock from insert | |||
| diesel::sql_query("CREATE UNIQUE INDEX ON users (name) WHERE name != 'Tess'") | |||
| // As tests can run concurrently, lock the table of interest. | |||
| diesel::sql_query("BEGIN; LOCK TABLE users; CREATE UNIQUE INDEX ON users (name) WHERE name != 'Tess'; COMMIT;") | |||
There was a problem hiding this comment.
AFAIK creating an index on a table shouldn't cause issues for parallel queries?
(Or if it does it should keep causing issues after creation)
There was a problem hiding this comment.
I've seen at least twice the following error in the CI checks (at sometimes it is not present):
---- update::upsert_with_sql_literal_for_target_with_condition stdout ----
thread 'update::upsert_with_sql_literal_for_target_with_condition' panicked at diesel_tests/tests/update.rs:374:10:
called `Result::unwrap()` on an `Err` value: DatabaseError(Unknown, "deadlock detected")
My assumption was that this is caused by the running the tests in parallel, as line 334 and 373 can both block the table. As I failed to get the tests running locally, I hoped my quick and dirty solution would solve the problem, apparently not :-(
Remove multiple statements
Two examples explain how PostgreSQL row data can correctly be interpreted as Rust data. This included an anonymous method with Record as also a safer method with FromSqlRow.