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

A check constraint the schema cannot name can never be retired, and keeps enforcing the old rule

Aperta
  • Qualcosa non va?
#107 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp, postgresql
Ambito
databases

Direzione di ricerca

Start by tracing column-level checkConstraint handling through the migrator and compare it with the legacy constraint names shown for usage_tracking.event_type. Use docs/reports/dataprovider-migrate-defects.md as the reproduction reference; done means a schema change can retire the pre-existing constraint and a newly allowed value is accepted after migration.

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

Descrizione

Summary

A column-level checkConstraint has no name field, so the migrator can only ever rewrite the constraint it created itself (<table>_<column>_chk). A check constraint that predates DataProvider, or was added by hand, can never be retired — and it keeps enforcing the old rule after the schema changes it.

Found by TradiSite on a production-shaped postgres:17 with 0.9.12-beta.

Reproduction

  1. Migrate a schema with a column checkConstraint on usage_tracking.event_type. DataProvider creates usage_tracking_event_type_chk.
  2. Simulate a legacy duplicate, as TradiSite production has: 
    ALTER TABLE public.usage_tracking
  ADD CONSTRAINT usage_tracking_event_type_check CHECK (event_type IN (...));
  3. Change the allowed values in the YAML and migrate again. DataProvider rewrites _chk and leaves _check in place.
  4. Insert a row using a newly allowed value: 
    ERROR: new row for relation "usage_tracking" violates check constraint "usage_tracking_event_type_check"

Why it matters

The migration reports success, the schema says the value is allowed, and the database rejects it. For an asynchronous writer that is silent data loss: the row is dropped and nothing surfaces it. TradiSite had to freeze event_type at exactly what production already enforces (their PR #140) rather than migrate at all.

Fix wanted

Either let a column checkConstraint carry an explicit name, or let the schema declare legacy constraint names to drop. Either lets pre-DataProvider constraints be retired through the sanctioned tool instead of by hand.

Related: #105. Reproduction write-up: docs/reports/dataprovider-migrate-defects.md in the TradiSite repository.

Lingua principale
C#
Stelle
67
Fork
4
Nessuna PR unita negli ultimi 30g

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 Nimblesite/DataProvider

Tutte le issue di Nimblesite/DataProvider

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.