Skip to content

README.md

Latest commit

 

History

History
65 lines (43 loc) · 6.03 KB

README.md

File metadata and controls

65 lines (43 loc) · 6.03 KB
Raw

db — Connexion et schéma SQLite

Table des Matières

  1. Journal des Mises à Jour
  2. Fonctionnalités Principales
  3. Index du Projet
  4. Base de Données
  5. Troubleshooting

Fonctionnalités Principales

  • connection.js : ouvre la connexion better-sqlite3 vers le fichier pointé par DB_PATH, active PRAGMA foreign_keys et le mode WAL. Expose un proxy avec une méthode reconnect() utilisée après une restauration de sauvegarde (voir routes/backup.routes.js).
  • schema.sql : DDL complet (tables, contraintes, seed des genres par défaut), source de vérité appliquée par scripts/init-db.js.

Index du Projet

db/
├── connection.js   # Connexion partagée (singleton via proxy)
└── schema.sql       # DDL + seed

Base de Données

Tables : families, consoles, games, game_platforms, screenshots, app_settings, genres, game_genres, game_platform_ownership_periods, console_ownership_periods, llm_settings (préférences uniquement, jamais de clé API), recommendations, recommendation_history.

Modèle multi-plateforme (depuis la refonte "plateformes multiples") : un jeu (games) est une fiche unique (titre, genres, note, notes, jaquette). Sa présence sur une ou plusieurs plateformes (PS5, Switch, Steam, Mobile...) est représentée par des lignes dans game_platforms — une relation many-to-many enrichie entre games et consoles, chaque ligne portant ses propres hours, completed, platform_type (Physique/Dématérialisé), dates et — pour les instances issues d'une synchronisation Steam — source='steam-sync', steam_appid, last_synced_at. consoles désigne donc toute plateforme de jeu, physique ou dématérialisée, pas seulement une console au sens strict. Les périodes de possession (game_platform_ownership_periods) sont rattachées à l'instance, pas au jeu global, car la date d'acquisition peut différer par support.

Différences notables par rapport à l'ancien schéma front-end :

  • games.cover_front / cover_back et screenshots.image_path stockent un chemin de fichier relatif (ex: covers/12_front.jpg) au lieu d'un data URL base64 inline.
  • llm_settings ne contient plus de colonnes llm_api_key_* — les clés vivent dans les variables d'environnement du serveur.

Une base encore au format "1 jeu = 1 console" (héritage V1) est migrée automatiquement vers ce modèle par scripts/migrate-to-multi-platform.js, invoqué par scripts/init-db.js avant l'application du schéma. L'ancienne table game_ownership_periods est conservée sous le nom game_ownership_periods_deprecated (filet de sécurité, suppression différée).

Catalogue standard de familles/consoles : sur une base tout juste créée (table families vide), scripts/init-db.js pré-remplit automatiquement un catalogue de référence (Sony, Nintendo, Microsoft, SEGA, Atari, PC, Mobile, Web... avec leurs consoles respectives — voir scripts/default-catalog.js). Une base ayant déjà ses propres familles/consoles, même partiellement ou avec une formulation différente (ex: "Playstation 1" au lieu de "PlayStation"), n'est jamais modifiée par ce catalogue — aucun risque de doublon sur une installation existante.

console_ownership_periods porte aussi model et serial_number (nullable, optionnels) — utiles quand la même console a été revendue puis rachetée dans une variante différente (ex: PS5 standard puis PS5 Slim). Ajoutés par scripts/init-db.js via ALTER TABLE ADD COLUMN idempotent sur les bases créées avant leur introduction.

Les deux tables de périodes de possession (console_ownership_periods et game_platform_ownership_periods) portent aussi acquisition_type (nullable, valeurs libres côté application : achat, pret, location) — précise comment le jeu ou la console a été obtenu(e) sur cette période. Pas de contrainte CHECK en base pour rester tolérant si de nouvelles valeurs sont introduites côté UI sans migration de schéma.

Volet financier des périodes de possession

Ces deux mêmes tables portent un jeu de colonnes identique, toutes nullables (NULL = non renseigné) :

Colonne Type Rôle
purchase_price REAL Prix d'achat. 0 (obtenu gratuitement) reste distinct de NULL (non renseigné)
purchase_from TEXT Vendeur (nom libre)
purchase_from_type TEXT personne | grande_surface | magasin_specialise | autre
sale_price REAL Prix de revente
sale_to TEXT Acheteur (nom libre)
sale_to_type TEXT Mêmes valeurs que purchase_from_type
purchase_notes TEXT Champ libre (accessoires fournis, état, circonstances de l'achat...)

Pourquoi sur les périodes et non sur consoles / game_platforms ? Une même console peut être achetée, revendue, puis rachetée : chaque période garde alors son propre prix, son propre vendeur et ses propres notes. Porter ces champs sur la console elle-même écraserait l'historique du premier achat à chaque rachat.

Les montants sont stockés en REAL (et non en centimes entiers) : sur une base personnelle, la lisibilité directe des valeurs en SQL prime sur la précision comptable au centime. Ces colonnes sont ajoutées aux bases antérieures par scripts/init-db.js (ALTER TABLE ADD COLUMN idempotent, comme model/serial_number/acquisition_type).

La normalisation des valeurs entrantes (prix négatif ou non numérique → NULL, texte vide → NULL, type d'interlocuteur hors liste → NULL) est centralisée dans backend/src/services/ownershipFinancials.js, partagé par les routes console et jeu+plateforme.

Troubleshooting

  • FOREIGN KEY constraint failed : vérifier que l'entité parente (console, jeu, genre) existe bien avant l'insertion — les contraintes FK sont actives (PRAGMA foreign_keys = ON).
  • Modifications non persistées après un docker compose down : vérifier que le volume ./bdd:/app/bdd est bien monté dans docker-compose.yml.