DashBoard/spec.md at 71c8102de68cf1f947388b4913fa37f534f93c14

Files

egg 71c8102de6 feat: dataset cache for hold/resource history + slow connection migration

Two changes combined:

1. historical-query-slow-connection: Migrate all historical query pages
   to read_sql_df_slow with semaphore concurrency control (max 3),
   raise DB slow timeout to 300s, gunicorn timeout to 360s, and
   unify frontend timeouts to 360s for all historical pages.

2. hold-resource-history-dataset-cache: Convert hold-history and
   resource-history from multi-query to single-query + dataset cache
   pattern (L1 ProcessLevelCache + L2 Redis parquet/base64, TTL=900s).
   Replace old GET endpoints with POST /query + GET /view two-phase
   API. Frontend auto-retries on 410 cache_expired.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-02-25 13:15:02 +08:00

2.8 KiB

Raw Blame History

MODIFIED Requirements

Requirement: Resource History page SHALL support date range and granularity selection

The page SHALL allow users to specify time range and aggregation granularity. On query, the page SHALL use a two-phase flow: POST /query returns queryId, subsequent filter changes use GET /view.

Scenario: Primary query via POST /query

WHEN user clicks the query button
THEN the page SHALL call POST /api/resource/history/query with date range, granularity, and resource filters
THEN the response queryId SHALL be stored for subsequent view requests
THEN summary (KPI, trend, heatmap, comparison) and detail page 1 SHALL all be populated from the single response

Scenario: Filter change uses GET /view

WHEN user changes supplementary filters (workcenter groups, families, machines, equipment type) while queryId exists
THEN the page SHALL call GET /api/resource/history/view?query_id=...&filters...
THEN no new Oracle query SHALL be triggered
THEN all charts, KPI cards, and detail table SHALL update from the view response

Scenario: Pagination uses GET /view

WHEN user navigates to a different page in the detail table
THEN the page SHALL call GET /api/resource/history/view?query_id=...&page=...

Scenario: Date range or granularity change triggers new primary query

WHEN user changes date range or granularity and clicks query
THEN the page SHALL call POST /api/resource/history/query with new params
THEN a new queryId SHALL replace the old one

Scenario: Cache expired auto-retry

WHEN GET /view returns { success: false, error: "cache_expired" }
THEN the page SHALL automatically re-execute POST /api/resource/history/query with the last committed filters
THEN the view SHALL refresh with the new data

Requirement: Resource History page SHALL display KPI summary cards

The page SHALL show 9 KPI cards with aggregated performance metrics derived from the cached dataset.

Scenario: KPI cards from cached data

WHEN summary data is derived from the cached DataFrame
THEN 9 cards SHALL display: OU%, AVAIL%, PRD, SBY, UDT, SDT, EGT, NST, Machine Count
THEN values SHALL be computed from the cached shift-status records, not from a separate Oracle query

Requirement: Resource History page SHALL display hierarchical detail table

The page SHALL show a three-level expandable table derived from the cached dataset.

Scenario: Detail table from cached data

WHEN detail data is derived from the cached DataFrame
THEN a tree table SHALL display with the same columns and hierarchy as before
THEN data SHALL be derived in-memory from the cached DataFrame, not from a separate Oracle query

2.8 KiB Raw Blame History