Adding report_combined table.
#5231
Conversation
There was a problem hiding this comment.
Before I continue, I'd like @Nutomic , @dullbananas input on this:
- This PR currently only adds the
report_combinedtable, and I'm thinking the other ones should be separate PRs. Doing a combined table for modlog is going to be really large, and it might be better to do each combined table one PR at a time.
| #[derive(Debug, Serialize, Deserialize, Clone, Default)] | ||
| #[cfg_attr(feature = "full", derive(TS))] | ||
| #[cfg_attr(feature = "full", ts(export))] | ||
| /// Report a comment. | ||
| pub struct CreateCommentReport { | ||
| pub comment_id: CommentId, | ||
| pub reason: String, | ||
| } |
There was a problem hiding this comment.
Just moved these to a reports specific mod.
| pub struct GetReportCountResponse { | ||
| #[cfg_attr(feature = "full", ts(optional))] | ||
| pub community_id: Option<CommunityId>, | ||
| pub comment_reports: i64, | ||
| pub post_reports: i64, | ||
| #[cfg_attr(feature = "full", ts(optional))] | ||
| pub private_message_reports: Option<i64>, | ||
| pub count: i64, |
There was a problem hiding this comment.
Since we now have a ReportsCombinedInternal::get_report_count(), it seems pointless to get each specific count, and make the front-ends add them, but I can revert this back if necessary.
| -- Combined tables triggers | ||
| -- These insert (published, item_id) into X_combined tables | ||
| -- Reports | ||
| -- Comment | ||
| CREATE FUNCTION r.report_combined_comment_report_insert () |
There was a problem hiding this comment.
@dullbananas I'm not sure if there's a better way to do this, or if we should create some kind of wrapper. It might be a bit verbose, especially when I start adding triggers for every mod table insert.
There was a problem hiding this comment.
Main changes are in here, and I've added tests for it.
| #[cfg_attr(feature = "full", derive(Queryable))] | ||
| #[cfg_attr(feature = "full", diesel(check_for_backend(diesel::pg::Pg)))] | ||
| /// A combined report view | ||
| pub struct ReportCombinedViewInternal { |
There was a problem hiding this comment.
I've tried to keep this struct as organized as possible, with the specific items first, then the shared last.
| @@ -248,6 +251,7 @@ pub fn config(cfg: &mut web::ServiceConfig, rate_limit: &RateLimitCell) { | |||
| .route("/like", web::post().to(like_post)) | |||
| .route("/like/list", web::get().to(list_post_likes)) | |||
| .route("/save", web::put().to(save_post)) | |||
| // TODO should these be moved into the new report heading? | |||
There was a problem hiding this comment.
I'm not sure if report actions should be moved to this new /report heading.
I'm leaning towards no, that it makes sense to keep them at the item-level: IE /post/report .
I'm also wondering whether we should get rid of /item/report/list entirely, and only support the combined one now.
| .service( | ||
| web::scope("report") | ||
| .wrap(rate_limit.message()) | ||
| .route("/list", web::get().to(list_reports)), |
There was a problem hiding this comment.
Either way, we need a report/list , somewhere.
| -- Creates combined tables for the following: | ||
| -- | ||
| -- Reports: (comment, post, and private_message) | ||
| -- Inbox: (Comment replies, post replies, comment mentions, post mentions, private messages) | ||
| -- Modlog: (lots of types) | ||
| -- Search: (community, post, comment, user, url) | ||
| -- TODO not sure about these two: | ||
| -- Home: (comment, post) | ||
| -- Community: (comment, post) | ||
| CREATE TABLE report_combined ( |
There was a problem hiding this comment.
These are all the places I can think of, to do a combined enum view: Reports, Inbox, Modlog, Profile, and Search.
I'm leaning towards not doing one for Home and Community, since showing new comments next to posts isn't going to be too useful (and the front page sorts are basically useless for comments, these combined tables can only sort by published.)
|
One other thing: @dullbananas can I get your assistance in using cursor pagination (using your library) instead of page / limit? It'd be a good idea to start using cursor pagination for these new combined responses. |
Context: #2444