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

Feature request: support DynamoDB multi-attribute GSI key schemas

Aperta
  • Qualcosa non va?
#155 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
aws, ruby
Ambito
databases

Direzione di ricerca

Inizia leggendo secondary_indexes.rb, il percorso _si_key_schema e la raccolta delle definizioni degli attributi utilizzata dalle migrazioni di TableConfig. Confronta il comportamento attuale di hash_key/range_key con la documentazione collegata di DynamoDB sui GSI con più attributi e traccia i flussi esistenti del modello e delle migrazioni. Il lavoro è completato quando una DSL e una rappresentazione della migrazione compatibili con le versioni precedenti possono generare schemi GSI con più attributi senza suddividere le dichiarazioni tra astrazioni diverse.

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

Descrizione

feature-request
Describe the feature

DynamoDB now supports multi-attribute key schemas for GSIs (up to 4 partition key attributes + 4 sort key attributes).

aws-record currently models GSIs as:

  • one hash_key
  • optional one range_key

Because of this, there is no way to define newer GSI key schemas using Aws::Record DSL or TableConfig migrations.

Use Case

In real single-table designs, we currently pack multiple dimensions into synthetic strings (for example STATUS#timestamp#suffix) only because the DSL is limited to one hash + one range key.

With native multi-attribute GSIs, users can:

  • avoid manual key concatenation/parsing
  • preserve native attribute types
  • express more access patterns with cleaner models
  • reduce app-side key-munging logic
Proposed Solution

Add first-class support for multi-attribute GSI keys while keeping backward compatibility.

Potential API shape:

global_secondary_index :tournament_region,
  hash_keys: %i[tournament_id region],
  range_keys: %i[round bracket match_id],
  projection: { projection_type: 'ALL' }

Backward-compatible behavior:

  • hash_key: -> treated as hash_keys: [hash_key]
  • range_key: -> treated as range_keys: [range_key]

Areas that would need updates:

  • index validation (secondary_indexes.rb)
  • key schema generation (_si_key_schema)
  • attribute definition collection in table config/migration paths
Other Information

Context links:

Observed current limit in aws-record main branch:

  • global_secondary_index expects hash_key/range_key
  • _si_key_schema emits only one HASH + optional one RANGE

Current workaround is using low-level Aws::DynamoDB::Client APIs directly for table/index creation, but then model/table declarations are split between two abstractions.

Acknowledgements
  • I may be able to implement this feature request
  • This feature might incur a breaking change
aws-sdk-ruby-record version used

2.14.0

Environment details (OS name and version, etc.)

Ruby 3.4.8, aws-sdk-dynamodb 1.161.0

Lingua principale
Ruby
Stelle
318
Fork
44
Merge medio
3g 15h
PR unite (30g)
4

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 aws/aws-record-ruby

Tutte le issue di aws/aws-record-ruby

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.