Files
danbooru/app/logical
evazion f49b3c439f posts: optimize modqueue page, status:modqueue, and status:unmoderated searches.
* Optimize status:modqueue and status:unmoderated searches. This brings them down from
  taking 500ms-1000ms per search to ~5ms.

* Change status:unmoderated so that it only filters out the user's disapproved posts, not
  the user's own uploads or past approvals. Now it's equivalent to `status:modqueue -disapproved:evazion`,
  whereas before it was equivalent to `status:modqueue -disapproved:evazion -approver:evazion -user:evazion`.
  Filtering out the user's own uploads and approvals was slow and usually unnecessary,
  since for most users it's rare for their own uploads or approvals to reenter the modqueue.

Before status:modqueue did this:

   SELECT * FROM posts WHERE is_pending = TRUE OR is_flagged = TRUE OR (is_deleted = TRUE AND id IN (SELECT post_id FROM post_appeals WHERE status = 0))

Now we do this:

   SELECT * FROM posts WHERE id IN (SELECT id FROM posts WHERE is_pending = TRUE UNION ALL SELECT id FROM posts WHERE is_flagged = TRUE UNION ALL SELECT id FROM posts WHERE id IN (SELECT post_id FROM post_appeals WHERE status = 0))

Postgres had a bad time with the "pending or flagged or has a pending appeal" clause because
it didn't know that posts can only be in one state at a time, so it overestimated how many
posts would be returned and chose a seq scan. Replacing the OR with a UNION avoids this.
2022-09-28 00:29:50 -05:00
..
2022-09-24 20:12:41 -05:00
2021-12-14 21:33:27 -06:00
2021-12-14 21:33:27 -06:00
2022-01-15 23:20:49 -06:00
2021-12-14 21:33:27 -06:00
2021-12-14 21:33:27 -06:00
2021-12-16 00:56:46 -06:00
2021-12-14 21:33:27 -06:00
2021-12-14 21:33:27 -06:00
2021-12-14 21:33:27 -06:00
2021-12-14 21:33:27 -06:00
2021-12-14 21:33:27 -06:00
2022-09-18 05:02:10 -05:00
2021-12-14 21:33:27 -06:00
2021-12-14 21:33:27 -06:00
2021-12-14 21:33:27 -06:00
2022-09-11 17:47:44 -05:00
2021-12-14 21:33:27 -06:00

Logical

This directory contains library code used through Danbooru. This includes things like defining API clients, dealing with sources, parsing tag searches, storing and resizing images, and so on.

Many of the files here use the Service Object pattern. Instead of putting complex code in models or controllers, it goes here, in plain old Ruby objects (POROs). This keeps models and controllers simpler, and keeps domain logic isolated and independent from the database and the HTTP request cycle.

External links