phiresky

You should also be able to make the from_error_and_type method an extension method on `Into`, then this code: ```rust PostRead::mark_as_unread(pool, &post_read_form) .await .map_err(|e| LemmyError::from_error_and_type(e, LemmyErrorType::CouldntMarkPostAsRead)) } ``` would look like...

here's a working extension trait: ```rust pub trait LemmyErrorExt { fn with_lemmy_type(self, error_type: LemmyErrorType) -> Result; } impl LemmyErrorExt for Result { fn with_lemmy_type(self, error_type: LemmyErrorType) -> Result { self.map_err(|e|...

> Instead of adding this as a separate sort option, how about changing the implementation of Hot/Active sort to use this logic? There are a lot of user complaints that...

> postgres said it ran out of memory If that's the case, this will probably need a new column in post_aggregates instead. From what I understand it would basically be...

I don't understand, why would it need to be separate columns? Wouldn't a simple additional filter on published be enough?

I don't understand how that could happen.. If you use the row_number() ranking then yes, but if you'd use one of the formulas suggested in #1206, then the absolute value...

I would caution against this change because it makes the pool less effective. You're allocating a postgresql connection (which is a fairly expensive whole process) when you don't actually need...

tbh i'm not sure. I guess it should be fine since it looks to be allocating connections in fairly limited time frames now. I'm not 100% sure though what the...

Ok, those sound like pretty good reasons. Having default trait implementation sounds good, I would not have thought that to be possible. I'm mainly just concerned since right now lemmy...

> but it should be effectively indistinguishable Yes, in that case that is true. I thought there would be calls that did the connection creation only later in the function...