Re: Introduce contributor badges

Hi

On Fri, 16 Oct 2026 at 10:09, Christoph Berg <myon(at)debian(dot)org> wrote:

> Re: Dave Page
> > The fix is xkeys, which the docs already
> > describe as the better option: tag the badge, people and profile
> responses
> > with something like `pgbadge_<id>` and give `Badge` a `purge_xkeys`. That
> > also replaces the per-holder URL loops.
>
> I don't think we'd want that. The people URLs have to be stable so
> people can link to them. if /contributors/people/myon/ gets replaced
> by /contributors/people/myon_123/, that's much less personal. The same
> applies to badges. (Or did I misunderstand the fix?)
>

You did :-)

Xkeys don't change any URL. An xkey is a tag that Django adds as a response
header (xkey: pgbadge_42). Varnish's xkey module indexes cached objects by
that tag, and pgweb can then say "purge everything tagged pgbadge_42"
without knowing which URLs those are. /community/people/myon/ stays exactly
as it is.

pgweb already does this. PgMiddleware tags every page with the templates it
used (pgweb/util/middleware.py:44), there's an @xkey decorator in
pgweb/util/decorators.py, and the post-save handler calls purge_xkeys on
any model that defines it (pgweb/util/signals.py:160). For badges it would
look like this:

- badge_view, profile and peoplelist add pgbadge_<id> to the response's
xkey header for every badge the page shows.
- Badge gets purge_xkeys returning pgbadge_<id>.

Saving or approving a badge would then purge every page that shows it,
including all holders' profile pages, which is item 3. It covers item 1 as
well: the removed holder's profile was tagged with that badge, and
simple_form saves the badge after the removal. Deletes (item 2) would still
need a post_delete hook, since that's a separate gap.

--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com