Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

xorq stat snapshot cache has no eviction and caches the batch aggregate as one entry — klass reloads can't be surgical

Abierto
  • ¿Algo no está bien?
#970 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
data

Línea de trabajo

Start by reading the cache key logic at xorq_stat_pipeline.py:197 and the batch aggregation at xorq_stat_pipeline.py:405. Then trace where cache_storage_path snapshots are loaded and written, and check the existing tests for cache behavior. Done means snapshots can be evicted without the reload wipe and, if pursued, individual stat aggregates can be reused independently.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

The xorq stat snapshot cache has no eviction, and its batch aggregate is a single cache entry. The only thing keeping the cache bounded today is tallyman wiping the whole entry directory on every klass reload (buckaroo-data/tallyman#177), which is unnecessary for correctness: snapshots are keyed on a content hash of each query (xorq_stat_pipeline.py:197), so klass changes never produce stale hits.

Removing that wipe exposes two gaps:

  • Snapshots for removed or edited stats are orphaned and accumulate under cache_storage_path indefinitely.
  • All batch stats go through one table.aggregate(agg_exprs) query (xorq_stat_pipeline.py:405), so adding or editing any one aggregate stat changes that query's key and re-runs every aggregate.

Impact

Without the wipe, disk use grows with every stat edit. With it, every hot-reload recomputes everything cold. Neither is what the summary-stat edit loop needs.

Suggested fix

  1. Eviction: a size cap or oldest-first pass over the snapshot directory (by mtime, touched on hit), run at load time rather than on reload.
  2. Optional, if the batch aggregate turns out to dominate on wide tables: cache the batch per stat function. On a run, look up each function's snapshot, aggregate only the missing ones in one query, write one snapshot per function, and merge. Costs more small files.

Context

Identified while reviewing the fix for #957. Tallyman side: buckaroo-data/tallyman#177.

Lenguaje dominante
Python
Estrellas
685
Forks
17
Merge medio
23 h 34 min
PR fusionados (30 d)
24

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de buckaroo-data/buckaroo

Todos los issues de buckaroo-data/buckaroo

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.