Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

EventStats: compiled queries endpoint for server-side aggregations

未关闭
#116 2 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 2 天内回复

@tmikula-dev 已经在做这个了。

开始于 2026年9月30日。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
冷清
技术栈
postgresql, python
领域
api, backend, databases

调研方向

首先解决依赖项 #115,并检查 event_stats_lambda.py 中现有的 EventStats 路由和处理程序流程,尤其是 ROUTE_HANDLERS,以及 PR #113。在设计注册表之前,与相关方确认受支持的查询集以及参数/输出契约。完成要求包括 routing、registry-lookup 和 result-shaping 的单元测试、一个填充了初始数据的 testcontainer 集成测试,以及 ./ci_local.sh 通过。

由索引模型根据 Issue 内容生成。

描述

enhancement
Feature Description

Extend the EventStats Lambda with a compiled queries endpoint — a curated list of predefined, server-executed queries (e.g. "failed jobs in the last 7 days", "job count aggregated by catalog") that consumers can invoke by name. Rather than pushing aggregation logic into the client or BI tool, the heavy lifting runs inside PostgreSQL and only the final result set is returned over the wire.

Problem / Opportunity

The current POST /stats/{topic_name} endpoint returns raw paginated rows. Consumers (dashboards, reports, downstream tools) re-derive the same aggregations repeatedly on the client side — wasting bandwidth, duplicating logic, and making results inconsistent across consumers. Predefined server-side queries centralise that logic, reduce payload sizes significantly, and allow PostgreSQL query planning to optimise repeated patterns.

Acceptance Criteria
  • A new route (e.g. POST /stats/{topic_name}/query/{query_name}) accepts a query identifier and an optional parameter bag (e.g. time window, tenant filter).
  • A SUPPORTED_QUERIES registry maps each query_name to its SQL template and accepted parameters — unknown names return 400.
  • Queries are executed server-side; only the aggregated result is returned (no raw row streaming).
  • The endpoint is protected by the same JWT auth and per-topic ACL as the rest of EventStats.
  • Unknown or unsupported query_name values produce a clear 400 error, not a 500.
  • Unit tests cover routing, registry lookup, and each query's result shaping.
  • Integration tests validate at least one aggregation query end-to-end against a seeded testcontainer database.
  • All quality gates pass (./ci_local.sh).

Note for implementer: the concrete set of queries and their SQL definitions must be identified and agreed upon as part of this issue's implementation. The examples below are starting points only — validate with stakeholders which aggregations are actually needed before writing SQL.

Proposed Solution

Introduce a CompiledQueryRegistry (or extend ReaderPostgres) that maps query names to parameterised SQL templates (using psycopg2 %s / sql.SQL composition — never string interpolation). Each entry declares its accepted input parameters and output schema.

Example candidate queries to evaluate with stakeholders:

  • failed_jobs_last_7d — count and list of jobs with a failure status in the last N days, grouped by pipeline/tenant.
  • aggregation_by_catalog — job count, success rate, and average elapsed time grouped by catalog/source.
  • run_status_summary — distribution of run statuses (running, completed, failed) over a configurable time window.

Route dispatch follows the existing ROUTE_HANDLERS pattern in event_stats_lambda.py. A new HandlerCompiledQuery (or an extension of HandlerStats) handles validation and delegates to the registry.

Dependencies / Related
  • Builds on the EventStats Lambda introduced in PR #113.
  • Connection pooling (#115) should be resolved first to avoid per-query connection overhead under aggregation load.
主要语言
Python
星标
4
派生
0
平均合并
1 天 20 小时
30 天内合并 PR
8

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

AbsaOSS/EventGate 的其他 Issue

查看 AbsaOSS/EventGate 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。