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

Consider JSONField in place of the RepositoryVersionContentDetails model

Abierto
  • ¿Algo no está bien?
#8,206 3 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, databases

Línea de trabajo

The pre-computed counts live in the RepositoryVersionContentDetails model in pulpcore/app/models/repository.py (around lines 1512-1527), and the version list reads them through pulpcore/app/serializers/repository.py (around line 248). Read both, then decide how a JSONField on RepositoryVersion would store and serialize the counts, which needs a maintainer decision and a migration. Done means the design is agreed, the migration and serializer output match the existing API, and the N+1 query is gone.

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

Descripción

Performance Task Triage-Needed

RepositoryVersionContentDetails serves as a pre-calculated content count originally intended to accelerate the repository version list endpoint.

It looks like this:

https://github.com/pulp/pulpcore/blob/3a8509e5d4684035974ddc4dac768903e70f7a4f/pulpcore/app/models/repository.py#L1512-L1527

One is saved per (rv, content_type, count, count_type) combination.

It might be better to just store the info in a JSONField on RepositoryVersion directly. That solves an N+1 issue as you would no longer need to perform additional (potentially many additional) queries to fetch counts for different content types or added/removed/present states, and likewise across different RVs. It may even be possible to serialize the value directly (or with minimal transformation). Note that N+1 is actually the case with the current repository version list operation, as the count objects are queried per-version (this is still much less expensive than the original count queries per version).

https://github.com/pulp/pulpcore/blob/3a8509e5d4684035974ddc4dac768903e70f7a4f/pulpcore/app/serializers/repository.py#L248

The schemaless drawbacks are somewhat minimal given the existing model already uses string types for content types and added/removed.

It may incur minor additional costs when querying RVs if it is not required. But likely (though not guaranteed) much less than the opposite case.

Lenguaje dominante
Python
Estrellas
606
Forks
174
Merge medio
16 h 44 min
PR fusionados (30 d)
107

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 pulp/pulpcore

Todos los issues de pulp/pulpcore

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.