[littleopa]

• Resolves: Database checks: Select_full_join warning is caused by the setup checks' own schema introspection #1245

Summary

Select_full_join and Join_without_index_rate can't be acted on by an admin, so this removes both rules (as suggested in review):

• The queries behind the counters aren't logged by default, so there is no way to tell which query did the join.
• Most of them come from Nextcloud itself: the core setup checks for missing columns, indices, primary keys and bigint conversions introspect the schema through information_schema, whose tables have no indexes. Every visit of Administration → Overview adds 12 to Select_full_join (see the analysis in Database checks: Select_full_join warning is caused by the setup checks' own schema introspection #1245), so on a small instance just looking at the page makes the check fail.
• Even if the query were known, adding an index by hand would make the schema check report it as unexpected.

Changes:

• remove both rules from RuleSet\Mysql
• remove them from Advisor::COUNTER_SENSITIVE_RULE_IDS
• remove AdvisorTest::testJoinWithoutIndexRateIsANotice (and the now unused Rule import)

Seen on Nextcloud 35.0.1, serverinfo 7.0.0, MariaDB 10.11 (Debian 12), all occ db:add-missing-* checks clean.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests are adjusted (the removed rule's test is dropped; no new behaviour to test)
• Screenshots before/after for front-end changes (not applicable)
• Documentation has been updated or is not required

AI (if applicable)

• The content of this PR was partly or fully generated using AI (Claude Code, Assisted-by trailer on the commit)

🤖 Generated with Claude Code

https://claude.ai/code/session_019TNUHUT6jaQ3BHvjvdf4Ny

[kesselb]

Thanks for your patch 👍

Is my understanding correct that the warning/notice isn't useful because the admin cannot act on it? The query that joins without an index isn't logged by default, so the admin can't tell which one it is. And even if they found it, adding the index manually would make our schema checker report it as an unexpected index.

If that's the case, I would suggest updating this PR to remove both Select_full_join and Join_without_index_rate.

[littleopa]

Thanks for the review, @kesselb! Yes, that's exactly it: the queries aren't logged by default, most of the full joins come from the core setup checks' own information_schema introspection, and a manually added index would show up as unexpected in the schema check.

I've updated the PR to remove both Select_full_join and Join_without_index_rate (rules, the COUNTER_SENSITIVE_RULE_IDS entries and the notice test), squashed into a single commit.

[kesselb]

/backport to stable35 please