From 6aceafda8ec513040a20bea4200ffe8bdbd4841c Mon Sep 17 00:00:00 2001 From: Marcel Date: Fri, 8 May 2026 09:20:49 +0200 Subject: [PATCH] docs(documents): TODO for SQL aggregation at 50k rows (#385) Documents the in-memory aggregation trade-off in getDensity so the next perf audit knows the row-count threshold at which to revisit. Addresses Markus's review concern. Co-Authored-By: Claude Opus 4.7 --- .../org/raddatz/familienarchiv/document/DocumentService.java | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/backend/src/main/java/org/raddatz/familienarchiv/document/DocumentService.java b/backend/src/main/java/org/raddatz/familienarchiv/document/DocumentService.java index 0a1adb07..bb2c9300 100644 --- a/backend/src/main/java/org/raddatz/familienarchiv/document/DocumentService.java +++ b/backend/src/main/java/org/raddatz/familienarchiv/document/DocumentService.java @@ -139,6 +139,11 @@ public class DocumentService { * with {@code findAll(spec)} and the archive size (≈5k docs) keeps this * well under the 200ms p95 target. Cache-Control: max-age=300 on the * controller layer absorbs repeated browse loads. + * + *

TODO: revisit when {@code documents > 50k} — at that scale move the + * aggregation into SQL (GROUP BY TO_CHAR(meta_date, 'YYYY-MM')) and accept + * that the criteria/specification surface needs a parallel native-query + * path. Surface this in the next perf audit. */ public DocumentDensityResult getDensity( String text, UUID sender, UUID receiver,