Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Consider JSONField in place of the RepositoryVersionContentDetails model

Aperta
#8,206 3 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend, databases

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
606
Fork
174
Merge medio
14h 6m
PR unite (30g)
101

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pulp/pulpcore

Tutte le issue di pulp/pulpcore

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.