Cpo

joined 1 year ago
sorted by: new top controversial old
sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 1 points 4 days ago

Thanks for the correction ๐Ÿ‘

sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 2 points 5 days ago

Thank you again and I will.

Typst 0.12 released in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 1 points 5 days ago

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

sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 1 points 5 days ago (2 children)

Not talking threads here, more Tokio tasks.

Typst 0.12 released in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 1 points 5 days ago (2 children)

DUDE!

You are the man!

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

๐ŸŽ‰

sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 4 points 5 days ago (2 children)

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 ๐Ÿ˜‰

sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 4 points 5 days ago (5 children)

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 ๐Ÿ™)

sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 1 points 5 days ago

Thanks! Will try that!

sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
[โ€“] Cpo@lemm.ee 2 points 5 days ago (4 children)

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.

sqlx::Transaction and Arc<Mutex<Transaction>> in c/rust@programming.dev
12
sqlx::Transaction and Arc<Mutex> (lemm.ee)
 

In order to share the running transaction into a DAO style data management class, I have wrapped the transaction in an Arc and pass it into the DAO.

The issue is, once the transaction is in there I cannot call commit() on it because it cannot be moved out of the Arc anymore, as the commit requires a mut self.

Any ideas on how to work around this?

Draw.Audio - Draw something, then listen to it. in c/internetisbeautiful@lemm.ee
[โ€“] Cpo@lemm.ee 2 points 5 days ago

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

view more: next โ€บ