14
sqlx::Transaction and Arc<Mutex>
(lemm.ee)
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Credits
Thanks for explaining further, it's a lot clearer now what you want to do. And no, I don't think this DAO thing is idiomatic for Rust and you probably don't want to do it like that. I'm not familiar with the pattern though, I'm not too much into OOP myself.
Anyways, I've worked a lot with axum and sqlx before so I can tell you what I'd do.
This makes sense. You just want a database connection pool (sqlx provides this) in your axum state so your handlers can get connections to the database.
Again, not sure what this DAO struct actually entails, but what I would do and have done in the past is just do exactly what you said before: "I want to pass around the transaction". So I would make my functions take the
Transaction
struct from sqlx (IIRC it has some type parameters and a life time but you can use a type alias to make it less verbose) and then I would just use that transaction in the function to call SQL. If you have a function that needs access to the database but doesn't need a transaction, you can just use a plain connection instead of a transaction.I'm not sure what you mean with "pass along during construction" but in any case, why do you want to avoid passing the transaction/connection? I feel like that is exactly what you should do. That is what you need to do anyway. Rust favours explicitness and you need to pass the transaction/connection to functions for them to use it, so just pass it.
It is now quite clear that I have to let go of OO paradigms. Maybe the package approach is perfectly fine.
Thank you for the insights and useful answer!
I have the idea that I am still only scratching the surface of rust, although I seem to manage it better every day.
As long as I leave my OO hat on the rack 😉
Definitely let go. Rust has some OOP features, but it's mostly just the OOP idea of interfaces, which Rust models with traits. You can also do dynamic dispatch, which is another OOP feature, but you should almost never use this in Rust unless you absolutely have to. Then there's encapsulation which is hugely important in Rust too, but yea outside of that kind of thing, I don't think OOP patterns are too useful. Honestly, if you ask me, many of these "OOP patterns" are really just solving problems that OOP causes in the first place.
Feel free to ask any other questions.
Thank you again and I will.