Thanks for the correction 👍

Thank you again and I will.

Exactly the same. Kicking of the binary now, but library could solve a lot of the security issues I was worried about.

Not talking threads here, more Tokio tasks.

DUDE!

You are the man!

I did know it was built in rust but never realized I could also use it as a library!

🎉

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 😉

Well. I did read up on the "XY" problem and apparently you assume that what I want to do is somehow bad practice.

To elaborate more on the problem: I am writing an axum backend which (like other backends) needs to do stuff in the database. As some endpoints update the database (and sometimes over multiple sql statements) I want to pass around the transaction as this embodies the connection I am using to update the database.

To separate the axum stuff (parameters, urls and whatnot) from the actual database logic, I've first pulled out all the database interactions into separate functions. Because those functions are logically groups (e.g. stuff happening with invoices, others with contacts etc), I thought it was a good idea to create a "dao" struct (and agreed: my OO brain kicked in here which might be debatable). This would group the interactions for each logical domain into a short-lived data access struct.

To prevent passing around the transaction/connection, i wanted to pass that along during construction, so the functions in the DAO could just access the connection when needed.

Non "OO" would be fine to be honest (just having all the DAO as functions in a separate package).

Sorry, no code, not at the computer atm.

(And yes, I am aware that rust is not OO, put away the pitchforks please 🙏)

Thanks! Will try that!

Seems like the into_inner is the way (i see other references to it).

And yes, transactions should be short-lived, this is just about delegating it to the responsible component.

Actually quite relaxing to create patterns on this! Great tip!

You, kind sir, deserve a reward.

Bravo!