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

Admin chapter workshops index is unbounded (no pagination + per-row COUNT queries)

Aperta
#2,899 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rails, ruby

Direzione di ricerca

Inizia da app/controllers/admin/workshops_controller.rb e dall’esempio di paginazione di #rsvp, quindi esamina app/views/admin/workshops/index.html.haml, dove vengono visualizzati i conteggi degli inviti accettati. Aggiungi una paginazione con limite e sostituisci i conteggi per riga con la ricerca aggregata descritta nell’issue; il lavoro è completato quando la pagina visualizza un numero fisso di righe e soddisfa i criteri indicati per il numero di query.

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

Descrizione

good first issue performance

Summary

Admin::WorkshopsController#index (/admin/chapters/:chapter_id/workshops) loads every workshop for the chapter and runs one extra SQL COUNT per rendered row. Slow on older chapters — chapter 1 (London) has ~13 years of workshops (~700+).

Symptom

  • One page view loads 700+ Workshop records and renders 700+ <tr> rows.
  • Each row's workshop.invitations.accepted.count emits a separate SQL COUNT — ~700 queries per page view.
  • Memory, DB time, and DOM size all scale with chapter age, so the page degrades as the chapter grows.

Root cause (two compounding problems)

1. Unbounded result set

app/controllers/admin/workshops_controller.rb:

@workshops = @chapter.workshops.includes(:sponsors)

No pagination. The view renders all rows in a single table.

2. N+1 COUNT queries in the view

app/views/admin/workshops/index.html.haml:

= workshop.invitations.accepted.count

One query per workshop per render. Each COUNT is cheap (index index_workshop_invitations_workshop_attending exists), but the round trips accumulate across all rows.

Proposed fix

Paginate with Pagy (already used elsewhere in this controller, e.g. #rsvp):

@pagy, @workshops = pagy(@chapter.workshops.includes(:sponsors), items: 50)

Ordering is already deterministic via default_scope { order('date_and_time DESC') } and index_workshops_on_date_and_time, so offset pagination is fine at codebar's scale.

Replace per-row COUNTs with one aggregate query, keyed by workshop id and looked up in the view:

@accepted_counts = @workshops.joins(:invitations)
                             .where(invitations: { attending: true })
                             .group('invitations.workshop_id').count

Optional follow-ups (only if still slow after the above)

  • Default the listing to upcoming + recent past (e.g. where(date_and_time: 1.year.ago..)) with a link to the full list.
  • Fragment caching per row — probably unnecessary once pagination lands.

Acceptance criteria

  • The page is paginated and renders a bounded number of rows regardless of chapter age.
  • Query count drops from O(workshops) to O(1): pagination count query + one aggregate + sponsors preload.
Lingua principale
Ruby
Stelle
104
Fork
205
Merge medio
1g 8h
PR unite (30g)
67

Guida per i contributori

Apri la guida per i contributori

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 codebar/planner

Tutte le issue di codebar/planner

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.