Cpo

joined 1 year ago
sorted by: new top controversial old
sqlx::Transaction and Arc<Mutex<Transaction>> in c/[email protected]
[โ€“] [email protected] 1 points 4 days ago

Thanks for the correction ๐Ÿ‘

sqlx::Transaction and Arc<Mutex<Transaction>> in c/[email protected]
[โ€“] [email protected] 2 points 5 days ago

Thank you again and I will.

Typst 0.12 released in c/[email protected]
[โ€“] [email protected] 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/[email protected]
[โ€“] [email protected] 1 points 5 days ago (2 children)

Not talking threads here, more Tokio tasks.

Typst 0.12 released in c/[email protected]
[โ€“] [email protected] 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/[email protected]
[โ€“] [email protected] 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/[email protected]
[โ€“] [email protected] 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/[email protected]
sqlx::Transaction and Arc<Mutex<Transaction>> in c/[email protected]
[โ€“] [email protected] 1 points 5 days ago

Thanks! Will try that!

sqlx::Transaction and Arc<Mutex<Transaction>> in c/[email protected]
[โ€“] [email protected] 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/[email protected]
14
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/[email protected]
[โ€“] [email protected] 2 points 5 days ago

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

16
Easiest way to block communities and other voyager tips (lemm.ee)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
4 comments fedilink
 

Voyager is my daily driver sofar. ~The only thing that bothers me is that blocking a community is quite the number of clicks away. ~

~When scrolling through "all" and seeing some community I am not interested in, i'd have to click the community name, see all the posts (which I am almost certain they will not interest me as they are a part of the community I want to block) then open the menu, click "block" then "community". And then retrace my steps back.~

~Subscribing is the same.~

Or is there a better way?

Got the tip of long-pressing the community name and then selecting "block community".

As there might be other pearls of uses to be found in Voyager, please post your tip below!

view more: next โ€บ