Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Consider JSONField in place of the RepositoryVersionContentDetails model

オープン
#8,206 コメント 3 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
backend, databases

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
606
フォーク
174
平均マージ
16時間 44分
マージ済み PR(30日)
107

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

pulp/pulpcore のほかの issue

pulp/pulpcore の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。