Add change detection and watermark tracking to extractors
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- go, google-cloud, kafka, mysql, postgresql
- Área
- backend, data-engineering, databases
Línea de trabajo
Empieza leyendo las interfaces de plugins en plugins/plugin.go y la orquestación del runner en runner/runner.go; después revisa runner/config.go, cmd/run.go y el extractor de BigQuery. Define los límites de state/watermark y cómo se mantiene disponible la extracción completa. Se considera terminado cuando los extractores de alto volumen enumerados puedan emitir metadatos de cambios y recurrir a la extracción completa cuando no exista ningún watermark.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Context
Meteor currently extracts everything on every run. For high-volume sources, this is wasteful and slow. Change detection allows extractors to emit only what changed since the last run.
Scope
- Define a watermark/checkpoint interface that extractors can implement
- Store watermarks between runs (local file, config store, or Compass state)
- Update high-volume extractors to support incremental extraction:
- BigQuery — use
INFORMATION_SCHEMAtimestamps for modified tables - Postgres/MySQL — track schema modification timestamps
- Kafka — track topic configuration changes
- BigQuery — use
- Emit change type metadata on records:
created,updated,deleted - Fall back to full extraction when no watermark exists
Design Considerations
- Watermark storage should be pluggable (local file for dev, remote store for production)
- Full extraction should remain available as a fallback or explicit mode
- Change detection accuracy varies by source — document limitations per extractor
Key Files
| Area | Location |
|---|---|
| Plugin interfaces | plugins/plugin.go |
| Runner orchestration | runner/runner.go |
| Runner config | runner/config.go |
| CLI run command | cmd/run.go |
| State store (new) | state/ |
| BigQuery extractor | plugins/extractors/bigquery/bigquery.go |
Why
Incremental extraction reduces load on sources, shrinks payloads, and enables faster refresh cycles. A graph that updates in minutes instead of hours is significantly more useful for AI agents.
References
- Lenguaje dominante
- Go
- Estrellas
- 241
- Forks
- 45
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de raystack/meteor
Todos los issues de raystack/meteor
Issues similares
-
docs: namespaceRegexes example teaches prefix matching, but regexes are matched as a substringAbiertotriage/pending-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
external-secrets/external-secrets#7117 ·
Los mantenedores suelen responder en 2 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ENTERPILOT/GoModel#1183 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
enhancement good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Edwin-metcalf/MetCode#16 ·
-
Action Required: Fix Renovate ConfigurationPosiblemente ocupada @thompson-tomo la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
open-telemetry/opentelemetry-collector#16170 ·
Los mantenedores suelen responder en 1 día
-
Buffer.writeRTX drops the RTCP returned by calc, so NACKs for other lost packets are never sentAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día