4.7 KiB
Utilisation de ks-store
Ouvrir le store
Le consommateur transmet uniquement le backend sélectionné et son objet d'options déjà résolu. Il ne construit jamais un pool PostgreSQL.
let options = match ks_store::StoreOpenOptions::new(
true,
"postgres",
serde_json::json!({
"url": database_url,
"max_connections": 10,
"connect_timeout_ms": 10_000,
"auto_initialize_schema": true
}),
) {
Ok(value) => value,
Err(error) => return Err(error),
};
let store = match ks_store::Store::open(options).await {
Ok(value) => value,
Err(error) => return Err(error),
};
Store::open interprète les options du backend actif, crée la connexion, exécute l'auto-initialisation lorsqu'elle est configurée et capture un résumé d'initialisation sanitisé. PostgreSQL reste le seul backend opérationnel exigé en 0.5.3-pre.002; un code backend inconnu est refusé proprement.
Résumés sûrs
let configuration = store.configuration_summary();
let initialization = store.initialization_summary();
let runtime = match store.runtime_summary().await {
Ok(value) => value,
Err(error) => return Err(error),
};
Ces contrats ne contiennent pas les options backend brutes. Le descripteur de connexion éventuellement exposé par runtime.backend est masqué par le backend propriétaire.
Le résumé d'initialisation classe les ressources par modèles logiques et fournit des compteurs. Il expose aussi objects, une liste de catégories physiques sans noms d'objets : PostgreSQL publie déjà le total table, tandis que pre.003 ajoutera le total index avec le nouveau baseline. Les noms physiques de tables, index et contraintes restent internes au backend.
Diagnostics de ressources
let raw_resources = match store.raw_resource_diagnostics().await {
Ok(value) => value,
Err(error) => return Err(error),
};
for resource in raw_resources {
println!(
"resource={} model={} available={}",
resource.resource_code,
resource.model_code,
resource.available
);
}
Les méthodes core_resource_diagnostics, decode_resource_diagnostics et known_resource_diagnostics suivent le même contrat backend-agnostique.
Contrats de repositories
Les traits publics effectivement implémentés sont :
StoreHealthStore;RawTransactionStore;CoreTransactionStore;CoreExtractionStore;DecodePipelineStore.
Store implémente ces traits et délègue au backend privé. Les anciens traits historiques sans implémentation réelle ont été retirés avant gel de l'API.
Replay et requêtes bornées
let candidates = match store.replay_transaction_candidates(filter).await {
Ok(value) => value,
Err(error) => return Err(error),
};
let programs = match store.replay_program_summaries(program_filter).await {
Ok(value) => value,
Err(error) => return Err(error),
};
let entities = match store.replay_entity_summaries(entity_filter).await {
Ok(value) => value,
Err(error) => return Err(error),
};
Les contrats publics utilisent ReplayTransaction*, ReplayProgram* et ReplayEntity*. Le scope d'instruction utilise désormais TopLevel, Inner et Logs; le terme historique outer n'est pas introduit dans la nouvelle API.
Pagination bornée
let first_page = ks_store::PageRequest::first_page();
let next_page = match ks_store::PageRequest::new(250, 250) {
Ok(value) => value,
Err(error) => return Err(error),
};
assert_eq!(first_page.limit, ks_store::DEFAULT_PAGE_SIZE);
assert!(next_page.limit <= ks_store::MAX_PAGE_SIZE);
La refonte cursorisée prévue par le plan 0.5.3 reste dans la tranche repositories/replay ultérieure.
Transactions atomiques
Les bundles CoreExtractionBundle, DecodePersistenceBundle et MaterializationPersistenceBundle regroupent les écritures qui doivent réussir ou être annulées ensemble. Les consommateurs ne doivent pas reproduire manuellement ces transactions avec des écritures SQL isolées.
Tests PostgreSQL réels
Les tests opt-in utilisent KS_SECRET_POSTGRES_TEST_URL. Aucun credential réel ne doit être enregistré dans les fixtures ou logs. Les erreurs d'ouverture de connexion sont volontairement sanitisées.
Limites de pre.002
- les tables restent temporairement sous leur namespace historique jusqu'à
pre.003; - les migrations PostgreSQL ne sont pas encore déplacées sous
migrations/postgres/; - la pagination cursorisée et l'invalidation descendante sont traitées dans la tranche repositories/replay ;
- la refonte complète des fenêtres desktop
demo_store_*est prévue dans la tranche consommateurs.