Cpo

joined 1 year ago
[โ€“] [email protected] 1 points 4 days ago

Thanks for the correction ๐Ÿ‘

[โ€“] [email protected] 2 points 4 days ago

Thank you again and I will.

[โ€“] [email protected] 1 points 4 days ago (2 children)

Not talking threads here, more Tokio tasks.

[โ€“] [email protected] 0 points 5 days ago (1 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!

๐ŸŽ‰

[โ€“] [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 ๐Ÿ˜‰

[โ€“] [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 ๐Ÿ™)

[โ€“] [email protected] 1 points 5 days ago

Thanks! Will try that!

[โ€“] [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.

 

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?

[โ€“] [email protected] 4 points 6 days ago

You, kind sir, deserve a reward.

Bravo!

[โ€“] [email protected] 0 points 6 days ago (3 children)

I am currently using it from a backend to generate pdfs.

One thing that prevents me from letting users build their own templates is the scripting capabilities. A joker creating an endless loop could block the whole server.

What would be nice is a "safe" mode in which no access to the file system (include and sorts) and limited runtime makes it safe to let users build their own templates.

 

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 โ€บ