La base de données

Chinaski stocke tout dans un seul fichier SQLite par instance (pas de serveur de base de données, pas d'identifiants, pas de protocole réseau) et garde son schéma à jour avec des migrations idempotentes qui s'exécutent automatiquement au démarrage.

Un fichier par instance

La base de données est un fichier unique chinaski.db, par défaut à la racine de l'application, ou là où pointe votre variable d'environnement CHINASKI_DB. Chaque instance que vous exécutez (chinaski@1, chinaski@prod, une copie de staging) a son propre fichier et ses propres réglages ; les modèles d'unités de production dérivent ces chemins par nom d'instance pour que les copies n'entrent jamais en collision.

Les connexions passent par un module partagé unique avec un jeu d'options canonique : les erreurs remontent immédiatement, le texte est propre en Unicode, et un busy timeout de 5 secondes empêche un fichier verrouillé de suspendre une requête. Le mode WAL est défini de façon persistante, pour que les lecteurs ne bloquent pas les écrivains et que la charge de travail typique (une session d'administration active plus des builds périodiques) reste réactive. Les contrôles de santé sur le point de terminaison de type /health vérifient lecture, écriture et mode de journal, avec un avertissement quand WAL n'est pas actif.

Comment le schéma évolue

Les installations neuves sont semées par schema.sql, le schéma complet d'une nouvelle base de données ; les scripts d'installation l'exécutent pour vous (ou vous pouvez exécuter sqlite3 chinaski.db < schema.sql à la main).
Les fichiers numérotés sous migrations/ ne sont pas appliqués mécaniquement aux instances en cours d'exécution. Ils documentent l'évolution et servent uniquement aux installations neuves.
Les instances déjà déployées se mettent à jour par des subs de migration idempotentes câblées dans une unique routine de démarrage. Chaque migration introspecte d'abord la base (la colonne ou la table existe-t-elle déjà ?) et ne fait rien si c'est le cas. Les cas de premier démarrage les sautent entièrement parce que schema.sql a créé la forme neuve.

Comme celles-ci s'exécutent au démarrage et sont idempotentes, mettre à niveau Chinaski se résume à : lancez le service et voilà ; l'instance répare son propre schéma en chemin.

Ce qu'il contient

Tout ce que le CMS gère : pages, billets, blocs, snippets, stacks, catégories, redirections, navigation, formulaires avec leurs soumissions, métadonnées de médias, documents, utilisateurs et sessions, les journaux auth/audit/event, le journal de build avec rapports de validation, le cache de rendu, les réglages clé-valeur, les historiques de révisions et les enregistrements d'exécution de sauvegardes.

Deux notes de confidentialité à connaître :

Les identifiants que vous saisissez dans les réglages (mots de passe SMTP, clés API, secrets de stockage) sont stockés chiffrés dans la base de données, à dérivation de votre secret d'instance, jamais en clair.
Un tampon de version de schéma lie la disposition du fichier aux attentes du code, et c'est le même numéro que le flux de sauvegarde/restauration vérifie : une base de données restaurée sur une instance de version différente est refusée plutôt qu'appliquée partiellement.

Santé et entretien

L'entretien est intégré : les jetons de réinitialisation de mot de passe expirés, les sessions mortes et les historiques de journaux bornés sont purgés automatiquement au démarrage et sur des temporisateurs périodiques. Le point de terminaison /health vérifie que la base peut être lue et écrite et signale le mode de journal, pour qu'une dérive de la configuration attendue soit détectée avant de mordre.

Les sauvegardes sont de simples copies de fichiers, aucun outil spécial requis, et les pages dédiées aux sauvegardes couvrent les instantanés, la rétention et la restauration.