-
Notifications
You must be signed in to change notification settings - Fork 4
fix: workaround ISTAT endPeriod+1 bug with post-query filter #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -118,6 +118,70 @@ def parse_sdmx_to_table(xml_content: str, dataflow_full_id: str) -> str: | |
| return '\n'.join(output_lines) | ||
|
|
||
|
|
||
| def filter_tsv_by_time_period(tsv_data: str, start_period: str | None, end_period: str | None) -> str: | ||
| """Filter TSV rows by TIME_PERIOD range (workaround for ISTAT endPeriod+1 bug). | ||
|
|
||
| The ISTAT SDMX API returns one extra year beyond the requested endPeriod. | ||
| This function filters out rows whose TIME_PERIOD falls outside the requested range. | ||
|
|
||
| Args: | ||
| tsv_data: TSV string with header row | ||
| start_period: Requested start period (e.g. '2024' or '2024-01-01') | ||
| end_period: Requested end period (e.g. '2024' or '2024-12-31') | ||
|
|
||
| Returns: | ||
| Filtered TSV string | ||
| """ | ||
| if not start_period and not end_period: | ||
| return tsv_data | ||
|
|
||
| lines = tsv_data.split('\n') | ||
| if not lines: | ||
| return tsv_data | ||
|
|
||
| header = lines[0].split('\t') | ||
| if 'TIME_PERIOD' not in header: | ||
| return tsv_data | ||
|
|
||
| tp_idx = header.index('TIME_PERIOD') | ||
|
|
||
| # Extract year as int for comparison | ||
| def extract_year(period_str: str) -> int | None: | ||
| try: | ||
| return int(period_str.split('-')[0][:4]) | ||
| except (ValueError, IndexError): | ||
| return None | ||
|
|
||
| start_year = extract_year(start_period) if start_period else None | ||
| end_year = extract_year(end_period) if end_period else None | ||
|
|
||
| filtered = [lines[0]] | ||
| removed = 0 | ||
| for line in lines[1:]: | ||
| if not line: | ||
| continue | ||
| parts = line.split('\t') | ||
| if len(parts) <= tp_idx: | ||
| filtered.append(line) | ||
| continue | ||
| row_year = extract_year(parts[tp_idx]) | ||
| if row_year is None: | ||
| filtered.append(line) | ||
| continue | ||
| if start_year and row_year < start_year: | ||
| removed += 1 | ||
| continue | ||
| if end_year and row_year > end_year: | ||
| removed += 1 | ||
| continue | ||
| filtered.append(line) | ||
|
|
||
| if removed: | ||
| logger.info(f'filter_tsv_by_time_period: removed {removed} rows outside [{start_period}, {end_period}]') | ||
|
|
||
| return '\n'.join(filtered) | ||
|
Comment on lines
+167
to
+239
|
||
|
|
||
|
|
||
| def filter_tsv_by_dimensions(tsv_data: str, dimension_filters: dict[str, list[str]]) -> str: | ||
| """Filter TSV rows by dimension values (client-side, post-API). | ||
|
|
||
|
|
@@ -388,6 +452,9 @@ async def handle_get_data( | |
| if params.dimension_filters: | ||
| table_data = filter_tsv_by_dimensions(table_data, params.dimension_filters) | ||
|
|
||
| # Step 8b: Filter by TIME_PERIOD (workaround for ISTAT endPeriod+1 bug) | ||
| table_data = filter_tsv_by_time_period(table_data, start_period, end_period) | ||
|
|
||
| # Step 9: Append curl command and query explanation | ||
| curl_info = _build_curl_info( | ||
| dataflow_id=params.id_dataflow, | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filter_tsv_by_time_periodclaims to filter rows outside the requested[start_period, end_period]range, but the implementation only compares the extracted year (YYYY) and ignores month/day within the same year. This can return out-of-range rows when callers provide more specific periods (e.g.,end_period='2024-03-31'), and it may also silently skip filtering ifstart_period/end_periodaren’t parseable into a year. Consider either (a) parsing and comparing full TIME_PERIODs for the supported formats (YYYY, YYYY-MM, YYYY-MM-DD, etc.) or (b) explicitly documenting/renaming this as a year-only filter and logging a warning when the period can’t be parsed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@copilot apply changes based on this feedback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in f817dc2. Replaced the year-only extraction with a
_parse_periodhelper that normalises all supported formats —YYYY,YYYY-MM,YYYY-MM-DD,YYYY-Qn(quarterly), andYYYY-Sn/YYYY-Hn(semester) — into(year, start_month, end_month)tuples. The filter now correctly excludes rows that fall outside the requested window at sub-year granularity (e.g.end_period='2024-03-31'removes Q2–Q4 rows). When a period string can't be parsed a warning is logged and that filter bound is skipped; rows with unparseable TIME_PERIOD values are kept. 35 unit tests covering all formats and edge cases were also added.