| 22 Jan 2020 |
| 23:17:54 |  Konstantin (Gitter) | Thx for help :) |
| 23 Jan 2020 |
| 16:25:04 |  tobx (Gitter) | Hey, I have some more general questions about Rust and derive. The Diesel examples talk about a Post and a NewPost struct. Post impl Queryable and NewPost impl Insertable. Now, the more my small test application grows, I realize, that I need more and more of thoses structs. E.g. I need some processing between deserialization and insert. So I have a struct DesirializedNewPost that can be converted to a InsertableNewPost. A Post derived from the database has information that are not meant for the user, so I first convert it into a SerializablePost. Furthermore I need a DesirializedPostUpdate and a InsertablePostUpdate struct. So for simple CRUD operations using the recommended derive options this is a lot of structs to define. Am I doing something wrong? |
| 20:13:16 |  Georg Semmler (Gitter) | @tobx That's not how I would structure the code. You don't need to have separate structs for deriving Queryable and Serialize or for Insertable/AsChangeset and Serialize. The details depend a bit on your exact use case. Normally you would just use the same struct for both derives. If you need to do some pre/postprocessing a combination of using tuples for diesel and #[serde(flatten)] is useful. To bring an simple example here: Supposed you are having some data set that are coming via some json api and you need to add a single field before inserting the data. In that case you would have a struct that derives Deserialize and Insertable and then do something like this: diesel::insert_into(some_table::table).values((your_struct_implementing_insertable, some_table::some_column.eq(something)).execute(&conn). The strategy works similar for updates. For queries normally a combination of custom select clauses and Queryable is sufficient. Otherwise just build a internal struct out of the values you can get from the database and wrap that into an outer struct adding the missing fields. You could just flatten that via #[serde(flatten)]. |
| 23:14:33 | tobx (Gitter) | Ok, I think I might have not the optimal database design, I guess with your tips I can improve that to achieve easier code. |
| 24 Jan 2020 |
| 00:45:49 | |  WebeWizard (Gitter) joined the room. |
| 00:45:49 | WebeWizard (Gitter) | Hey all. Fairly new to Diesel, trying to use mysql backend. It seems like operations like '+' are not implemented for mysql Unsigned<T> types. Can anyone confirm? I don't see any open issues related to it |
| 04:50:10 | WebeWizard (Gitter) | trying to use it in update/set .set(CardDSL::deck_pos.eq(CardDSL::deck_pos + 1)) where deck_pos is an Unsigned<Smallint> |
| 05:32:42 | WebeWizard (Gitter) | ended up submitting a PR that auto generates ops like all the other types diesel-rs/diesel#2278 . |
| 09:14:16 | |  Etienne (Gitter) joined the room. |
| 09:14:31 | Etienne (Gitter) | Hey guys what do you think about using sqlx inside diesel ? https://github.com/launchbadge/sqlx |
| 09:14:48 | Georg Semmler (Gitter) | Can you explain what you expect from doing that? |
| 09:25:49 | Etienne (Gitter) | The async part and the type safe sql |
| 09:26:32 | Etienne (Gitter) | But i don't know the internal structure of diesel, perhaps it's a stupid suggestion |
| 09:27:22 | Georg Semmler (Gitter) | We have already type safe sql. (I would say even more type safe then that what sqlx can offer). For async: I do not see that they solve our main blocker for writing a async interface: Having a sane transaction api, that does not require someone to call explicitly commit or abort. |
| 09:46:45 | Etienne (Gitter) | Ok thanks for the explanations ! |
| 09:47:18 | Etienne (Gitter) | I have another question, is there a way to handle concurent insertions with diesel ? |
| 09:47:39 | Georg Semmler (Gitter) | Concurrent in which way? |
| 09:47:58 | Etienne (Gitter) | In kube i distribute my software and all of them can insert and read data in the same postgres database |
| 09:48:45 | Georg Semmler (Gitter) | Yes, that's fine. Open a connection to the postgres database and run whatever sql statement you want. Postgres can handle that. |
| 09:49:18 | Etienne (Gitter) | But what will append if two instances are asked to create the same object ? |
| 09:49:26 | Etienne (Gitter) | Diesel will send me an error ? |
| 09:49:53 | Georg Semmler (Gitter) | Postgres will generate that error, diesel will only give you the error message postgres has generated. |
| 09:50:45 | Georg Semmler (Gitter) | (Assumed that the "same object" is somehow forbidden by some unique constrain at database level.) |
| 09:51:21 | Etienne (Gitter) | (yes good assumption) |
| 09:51:45 | Etienne (Gitter) | Ok so i have just to do the good error handling if diesel send me an already exist error |
| 09:52:01 | Georg Semmler (Gitter) | Yes |
| 09:53:10 | Etienne (Gitter) | Thank you very much ! |
| 09:53:14 | Georg Semmler (Gitter) | There is a separate error variant for this case: http://docs.diesel.rs/diesel/result/enum.DatabaseErrorKind.html#variant.UniqueViolation, so just match on the error and see if it's this variant. |
| 09:55:51 | Etienne (Gitter) | Perfect ! |
| 13:28:51 | |  ejiek joined the room. |
