71c8102de6
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>
47 lines
2.8 KiB
Markdown
47 lines
2.8 KiB
Markdown
## 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
|