ks-store

ks-store porte la frontière de persistance généraliste de Khadhroony Solana. Les consommateurs utilisent des contrats fonctionnels et une façade Store indépendante du moteur concret ; PostgreSQL reste l'implémentation opérationnelle de 0.5.3, confinée à l'intérieur de la crate.

Périmètre

La crate expose :

Store et StoreOpenOptions comme façade d'ouverture et handle persistant backend-agnostique ;
les DTO et entités raw, observations, Core, décodage, matérialisation et ledger ;
les traits async StoreHealthStore, RawTransactionStore, CoreTransactionStore, CoreExtractionStore et DecodePipelineStore ;
les filtres et résultats de replay sans préfixe backend ;
des diagnostics et résumés runtime/init sanitisés ne révélant ni secret ni nom physique d'objet ;
des transactions atomiques pour extraction, décodage et matérialisation.

Frontière backend

PostgresStore, PostgresStoreOptions, sqlx::PgPool, les requêtes SQL et les noms physiques de tables sont privés à ks-store. ks-pipeline, les scénarios et les applications ne doivent connaître que Store, les repositories et les DTO fonctionnels.

ks-store ne dépend pas de ks-config. Un consommateur lui fournit un backend sélectionné et un objet backend_options opaque ; seul ks-store interprète et valide les paramètres PostgreSQL puis crée la connexion.

Configuration et sécurité

StoreOpenOptions ne dérive pas Debug et ne rend pas les options backend accessibles après construction. Les résumés publics exposent uniquement des informations explicitement sanitisées : code backend, présence d'une connexion, état d'initialisation, health, modèle logique et compteurs.

Le backend PostgreSQL masque le descripteur de connexion et utilise l’unique target de crate ks-store, complété par backend="postgres", domain="ks-store.pg" et un champ action structuré. Aucun DSN, password ou valeur bindée n'est destiné aux diagnostics publics.

Schéma pendant `0.5.3`

0.5.3-pre.002 ne modifie pas encore les tables héritées kb_sol_*. Leur reconstruction sous k_sol_*, les ressources SQL atomiques et le gel N1/N2/N3 commencent en pre.003 conformément au plan actif.

Responsabilités

garantir les invariants des données persistées ;
posséder la connexion et l'initialisation du backend actif ;
fournir des frontières async typées au pipeline ;
protéger les opérations multi-tables par transactions ;
borner les diagnostics et replay exposés ;
permettre le remplacement futur de PostgreSQL sans réécriture des consommateurs.

Hors périmètre

La crate ne décode pas les instructions, n'acquiert pas les transactions et ne décide pas quelle matérialisation ou projection N4 exécuter. Elle persiste les faits produits par ks-lib et orchestrés par ks-pipeline.

Relations

dépend de ks-core pour les erreurs ;
utilise les contrats de replay de ks-lib ;
est consommée principalement par ks-pipeline, ks-pipeline-demo-scenarios et kb-app-demo-desktop ;
ne dépend pas de ks-config.

3.4 KiB Raw Blame History Unescape Escape