Summary

RepeatedSingleInsertDetector warns when the same INSERT statement runs more than its threshold (default 3). It does not exclude tables whose name signals a deliberate staging or temp use, so common patterns like "load 100 rows into a temp table, then bulk-process" produce noise warnings.

Location

query-audit-core/src/main/java/io/queryaudit/core/detector/RepeatedSingleInsertDetector.java — evaluate() body around lines 44-68.

Reproduction

Four single-row inserts into a staging table:

INSERT INTO temp_staging VALUES (1, 'a')
INSERT INTO temp_staging VALUES (2, 'b')
INSERT INTO temp_staging VALUES (3, 'c')
INSERT INTO temp_staging VALUES (4, 'd')

Detector output:

[WARNING] REPEATED_SINGLE_INSERT on table 'temp_staging'
  Single-row INSERT executed 4 times on table 'temp_staging'.
  Each INSERT causes a separate network round-trip and log flush.
  Suggestion: Use batch INSERT (addBatch/executeBatch ...)

Temp / staging tables are typically session-local, in-memory, or otherwise cheap; the round-trip / log-flush cost the suggestion warns about does not apply (or applies very weakly).

Expected vs actual

Impact

Confirmed-issue tier. Real-world test fixtures and ETL-style code paths trip this rule on every run, forcing users to either suppress per-table or rewrite legitimate code.

Suggested direction

• Exclude tables matching common conventions: temp_*, *_temp, tmp_*, *_tmp, staging_*, *_staging. Case-insensitive.
• Make the pattern set configurable (repeated-insert.exclude-tables: ["temp_*", "*_staging", "etl_*"]).
• Optionally treat MySQL CREATE TEMPORARY TABLE and Postgres CREATE TEMP TABLE as a hint to skip the rule for that table for the rest of the test (out of scope for the first fix).

Acceptance

• The repro queries produce no issue under defaults.
• An equivalent loop into a normal table (INSERT INTO orders ... × 4) still warns.
• The exclusion list is configurable via application.yml / programmatic config.