Repository navigation
feat: extend card-patch system with name/subTypes fields + backfill u… - #76
Open
julesduroux wants to merge 1 commit into
Open
julesduroux wants to merge 1 commit into
julesduroux wants to merge 1 commit into
Conversation
…nique names from their family
CardPatchValidator/CardPatchService only supported scalar Card fields
and boolean CardGroup flags. Adds two more field categories needed to
fix the real discrepancies found while auditing CardsData vs Equinox:
- LOCALIZED_CARD_FIELDS ("name"): an object {locale: text}, routed to
Card's own CardTranslation, exact reference only.
- LIST_CARD_GROUP_FIELDS ("subTypes"): a full-replacement array of
references, routed to CardGroup, exact or wildcard reference.
CardGroup::removeSubType() didn't exist yet, needed for the replace.
Includes the one confirmed subTypes correction (4 prints: COREKS
AX_28 family, EOLE LY_108_R2).
Separately: a broad backfill migration for unique card names. Unique
prints are imported from their own per-instance Equinox JSON, and for
a number of families that JSON carries a wrong/English-leaked name in
some locales - while the non-unique printing sharing the same
faction+number slot (same in-universe character) already has the
correct translation. Verified against CardsData's full referential
that a (faction, number) pair never maps to more than one card family,
across sets or between unique/non-unique, so matching purely on that
pair is safe. Runs family by family (own transaction each, via a
temporary PL/pgSQL procedure) rather than one bulk UPDATE, since some
families have 10k+ serialized instances.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1. Extension du patch system
CardPatchValidator/CardPatchServicene géraient que des champs scalaires(Card) et des booléens (CardGroup). Ajout de deux catégories :
name(localisé) : objet{locale: texte}, routé versCardTranslation,référence exacte uniquement (chaque exemplaire a sa propre traduction).
subTypes(liste) : remplacement complet du tableau de sous-types, routévers
CardGroup, référence exacte ou wildcard.CardGroup::removeSubType()n'existait pas encore, ajouté pour permettre ce remplacement.
Inclut le seul correctif
subTypesconfirmé (4 imprimés : famille COREKSAX_28, EOLE LY_108_R2).
2. Backfill des noms des cartes uniques (migration)
En auditant les écarts CardsData vs Equinox, on a découvert que les cartes
uniques sont importées depuis leur propre JSON Equinox par exemplaire, et
que pour un certain nombre de familles ce JSON porte un nom erroné dans
certaines langues (texte anglais qui a fuité dans le mauvais champ de
langue) — alors que la carte commune/rare partageant le même couple
faction+numéro (le même personnage dans l'univers du jeu) a déjà la bonne
traduction.
Vérifié sur l'intégralité du référentiel CardsData (3 469 impressions
non-uniques + 5,4M impressions uniques) : un couple (faction, numéro) ne
pointe jamais vers plus d'une famille, ni entre sets, ni entre unique/non-
unique — le rapprochement par ce seul couple est donc fiable, sans risque de
collision.
La migration (
Version20260911180000) réaffecte le nom de chaque carte/groupe unique depuis sa commune, famille par famille (une transaction
par famille via une procédure PL/pgSQL temporaire) plutôt qu'un seul gros
UPDATE — certaines familles dépassent 10 000 exemplaires sérialisés, un
UPDATE global aurait verrouillé la table
card_translationtrop longtemps.part) — recommandé de tester le dry-run/l'effet sur un échantillon avant
déploiement en prod, je n'ai pas pu le valider en conditions réelles faute
de temps sur cette itération.
À exécuter après merge
php bin/console app:meilisearch:index --fields=variation # si pas déjà fait en Phase 2
php bin/console app:cards:apply-patches --dry-run
php bin/console app:cards:apply-patches