FlexMeasures / flexmeasures / 41326095030

88%

push

github

Avoid recursive data scans while rendering delete controls (#2788)

* fix: skip recursive data scans while rendering delete controls

Signed-off-by: Enoch <bferanmi806@gmail.com>

* Look up a subtree's sensors before probing whether they hold data

asset_contains_data probed timed_belief with a subquery for the subtree's sensors.
Postgres planned that as a merge join over the whole timed_belief index,
so on a table of 20 million beliefs the probe took over two seconds whenever the subtree held no beliefs, however small it was.
It now fetches the subtree's asset and sensor IDs first and names them in the probes,
which Postgres looks up in the index: 31 ms at most on the same database, for a tree of 1000 sensors.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWv6v3qq916tT9BKtL4ji7
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Check for data again before showing delete buttons, now that it is quick

With the probe looking up sensors by ID, the asset and sensor pages can again tell whether a user may delete what they show,
rather than offer the button to every member and let deletion fail on data.
So members keep a delete button for assets and sensors without data, as the API lets them delete those,
and users who may delete data skip the query altogether.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWv6v3qq916tT9BKtL4ji7
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Drop the changelog entry for a slowdown that was never released

The scan came in with #2607, which is not released yet.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWv6v3qq916tT9BKtL4ji7
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Stop telling users they cannot delete the copies they make

The copy buttons noted "you can copy but not delete" to whoever may not delete the asset shown.
But that... (continued)

15 of 16 new or added lines in 3 files covered. (93.75%)

22919 of 26282 relevant lines covered (87.2%)

0.87 hits per line