Filter games version 3

[alice-blue]

Slightly more verbose message. Fixed the spacing before the message (by using <p>) so that the spacing is about the same whether there is one result or multiple results. Changed some variable names to be clearer (taking out "search" since the game results aren't always the result of obvious searches). Also, the formatting doesn't look so strange anymore (I never figured out the cause). There's now a default value for the $override_game_filter parameter (though I don't know if it'll help much).

[alice-blue]

Here's a screenshot of "no results found." I didn't get a screenshot of the other one.

[alice-blue]

Revised it again.

[dfabulich]

Oh, also, it's conflicted, but perhaps the deeper problem is that I'm conflicted about this PR. 😖

[dfabulich]

I spent some time on this over the weekend and I think we're in better shape than I thought!

In #1314 I fixed a bug where approximately all searches were doing full-scan queries. This automatically fixed the two existing homepage searches (for new games and IFDB recommends).

The primary scary part of this PR was searching for reviews using doSearch (ordered by "recently reviewed").

Well, when I merge the main branch into this branch, (after manually resolving conflicts in incoming-schema-changes.sql, which is pretty easy because main's version is blank), I found that it, too, was no longer doing a full-scan query, so we're good to go!

`lastReviewDate` `analyze` query

MariaDB [ifdb]> analyze select
    ->     games.id as id,
    ->             games.title as title,
    ->             games.author as author,
    ->             games.desc as description,
    ->             games.tags as tags,
    ->             games.created as createdate,
    ->             games.moddate as moddate,
    ->             games.system as devsys,
    ->             if (time(games.published) = '00:00:00',
    ->                 date_format(games.published, '%Y'),
    ->                 date_format(games.published, '%M %e, %Y'))
    ->                 as pubfmt,
    ->             if (time(games.published) = '00:00:00',
    ->                 date_format(games.published, '%Y'),
    ->                 date_format(games.published, '%Y-%m-%d'))
    ->                 as published,
    ->             date_format(games.published, '%Y') as pubyear,
    ->             (games.coverart is not null) as hasart,
    ->             avgRating as avgrating,
    ->             numRatingsInAvg as ratingcnt,
    ->             stdDevRating as ratingdev,
    ->             numRatingsTotal,
    ->             numMemberReviews,
    ->             lastReviewDate,
    ->             starsort,
    ->             games.sort_title as sort_title,
    ->             games.sort_author as sort_author,
    ->             ifnull(games.published, '9999-12-31') as sort_pub,
    ->             games.pagevsn,
    ->             games.flags
    ->
    -> from
    ->     games
    ->             join gameRatingsSandbox0_mv on games.id = gameid
    ->
    -> where
    ->     1 and not exists (select 1 from gametags where games.id=gameid and tag in ('beginner'))
    ->
    ->
    ->
    -> order by
    ->     lastReviewDate desc
    ->
    -> limit 8 \G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: gameRatingsSandbox0_mv
         type: index
possible_keys: PRIMARY
          key: lastReviewDate
      key_len: 5
          ref: NULL
         rows: 14371
       r_rows: 9.00
     filtered: 100.00
   r_filtered: 100.00
        Extra:
*************************** 2. row ***************************
           id: 1
  select_type: PRIMARY
        table: games
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 130
          ref: ifdb.gameRatingsSandbox0_mv.gameid
         rows: 1
       r_rows: 1.00
     filtered: 100.00
   r_filtered: 88.89
        Extra: Using where
*************************** 3. row ***************************
           id: 2
  select_type: MATERIALIZED
        table: gametags
         type: ref
possible_keys: gameid,tag
          key: tag
      key_len: 1002
          ref: const
         rows: 40
       r_rows: 35.00
     filtered: 100.00
   r_filtered: 100.00
        Extra: Using where

Here's how I generated this analysis:

• I logged in and set -tag:beginner in my user settings (which excludes just the most recent review of "Their First Meeting" in the June archive dump)
• I set $logging_level = 1 in searchutil.php.
• I visited the home page and copied and pasted the query from the Docker log
• In VS Code, I used regex find and replace to replace \\n with \n, fixing new lines
• I added analyze to the beginning of the query, replaced the ? in the where section with 'beginner', and added \G at the end, instead of a semicolon, displaying the results vertically
• I copied and pasted the resulting query into ./query-docker.sh

Especially note that I needed to use analyze to see that this query was OK instead of just using explain, something that I (re?)learned about in 2025. rows indicates that the query planner thinks it's gonna have to do a full scan of the index, but r_rows shows that the query planner guessed wrong; it only had to look at 9 rows to return 8 rows of results, skipping the first one because it had the beginner tag. The query planner's pessimism doesn't hurt our actual query performance, so this is OK to ship!

Here's the next steps:

1. Resolve conflicts on this branch. Note that the branch is also in conflict with Rename "components" folder to "home-components" #1310, so when we merge one of them, we'll have to resolve conflicts on the other; I propose to merge this PR first, and Rename "components" folder to "home-components" #1310 second.
2. I filed a couple of PRs on this PR Add lastReviewDate to gameRatingsSandbox01 alice-blue/ifdb#11 and Patch full schema alice-blue/ifdb#12

With that done, I'll queue up a deploy and finally merge this thing.

[alice-blue]

Ok, I merged your PRs. (I didn't test anything.)

[alice-blue]

I'm not sure how to fix the conflicts. The filetypes stuff looks familiar, but maybe from an old, unrelated PR.

Aside from the filetypes stuff, I see this:

alter table reviewvotes
    add column `reviewvoteid` bigint(20) unsigned NOT NULL AUTO_INCREMENT FIRST,
    add column `createdate` datetime NOT NULL DEFAULT current_timestamp(),
    add PRIMARY KEY (`reviewvoteid`)
;


-- Add column for game search filter to the users table

ALTER TABLE `users` ADD COLUMN `game_filter` VARCHAR(150) DEFAULT '';

and this:

CREATE TRIGGER games_insert
AFTER INSERT ON games FOR EACH ROW
call refresh_gameRatingsSandbox0_mv(NEW.id);

CREATE TRIGGER games_delete
AFTER DELETE ON games FOR EACH ROW
call refresh_gameRatingsSandbox0_mv(OLD.id);

The only one that seems relevant to this PR is the "game_filter" one, so maybe we keep that? I don't know what to do with the others.

[dfabulich]

The idea of incoming-schema-changes.sql is that it's intended to take an old database dump from the IF Archive and update it to the latest database schema. incoming-schema-changes.sql gradually accumulates incoming changes until a new quarterly database dump arrives on the IF Archive. When I update main to use a newer database dump, I delete everything in incoming-schema-changes.sql in the main branch, because all of those changes had already been applied to the production database months ago.

In this PR, you just added one line to incoming-schema-changes.sql at the top of the file. In the main branch, the file changed out from under you, removing all of the lines of the file. Resolving the conflict means using the main blank version and re-adding just the one line you actually intended to add.

[alice-blue]

@dfabulich, I think I resolved this.

[alice-blue]

I added this space at the end of the string in line 357 when I was trying to figure out the problem, and then didn't take it out. It might not be needed though.