0.3.16-pre.009
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: crates/ksp-store-postgres-lib/README.md -->
|
||||
<!-- version: 11 -->
|
||||
<!-- version: 12 -->
|
||||
|
||||
# ksp-store-postgres-lib
|
||||
|
||||
@@ -63,7 +63,18 @@ VerifyFull
|
||||
|
||||
Le moteur de migrations embarqué vérifie version logique, nom et checksum SHA-256, sérialise les runners par advisory transaction lock et refuse une history divergente ou plus récente que le runtime.
|
||||
|
||||
Le bootstrap metadata est conservé comme migration V000. La migration logique V001 matérialise le schéma `RawTransaction` et V002 le schéma `RawAccountState`, chacune en ressources séparées `tables/`, `constraints/` et `indexes/` afin que le backend puisse vérifier leur compatibilité effective sans transformer les fichiers SQL en parser généraliste.
|
||||
Le bootstrap metadata est conservé comme migration V000. La migration logique V001 matérialise le schéma `RawTransaction`, V002 le schéma `RawAccountState` et V003 ajoute le sidecar multi-variantes `RawTransaction`. V000/V001/V002 restent byte/checksum-identiques. Les migrations sont découpées en ressources `tables/`, `constraints/` et `indexes/` afin que le backend puisse vérifier leur compatibilité effective sans transformer les fichiers SQL en parser généraliste.
|
||||
|
||||
V003 ajoute exactement les quatre tables métier suivantes :
|
||||
|
||||
```text
|
||||
ksp_raw_transaction_variants
|
||||
ksp_raw_transaction_canonical_selectors
|
||||
ksp_raw_transaction_observation_variants
|
||||
ksp_raw_transaction_conflicts
|
||||
```
|
||||
|
||||
Le conflict case V003 de `0.3.16` est volontairement minimal (`Open`/réouverture idempotente, relation/reason/revision). Le lifecycle complet de résolution/historique est reporté à `0.3.17`.
|
||||
|
||||
La base est liée à un seul `RawNetworkId` via `ksp_store_identity`. Une migration enregistrée mais physiquement divergente est un mismatch ; les réparations additives sûres dépendent de `schema_autoupdate`.
|
||||
|
||||
@@ -108,9 +119,9 @@ persist_raw_transaction_acquisition
|
||||
record_raw_transaction_observation
|
||||
```
|
||||
|
||||
L'acquisition canonique et son observation initiale sont commises dans une seule transaction PostgreSQL. Les clés uniques physiques fournissent l'admission idempotente ; après un conflit unique, le backend verrouille la ligne gagnante et compare le contenu réel avant de conclure `AlreadyPresent` ou `Conflict`.
|
||||
L'acquisition et son observation sont commises dans une seule transaction PostgreSQL. Après collision d'identité, le backend verrouille la ligne V001 avec `FOR UPDATE`, compare le contenu via le comparateur partagé puis persiste/réutilise la variante reçue. `Exact` et `CompatibleLessComplete` conservent le canonique, `CompatibleMoreComplete` met à jour atomiquement selector V003 et projection V001, tandis que `Conflict`/`Incomparable` ouvrent ou mettent à jour un conflict case durable sans modifier le canonique. La nouvelle observation est rattachée à la variante réellement reçue avant `COMMIT`.
|
||||
|
||||
Un tombstone `Purged` compatible produit `SkippedPurged/NotRecorded` en mode normal. `ForceRehydrate` restaure explicitement le payload `Full` et l'observation dans la même transaction.
|
||||
Un tombstone `Purged` compatible produit `SkippedPurged/NotRecorded` en mode normal. `ForceRehydrate` restaure explicitement le payload `Full` et l'observation dans la même transaction. `content_hash` n'est qu'un préfiltre : les bytes disponibles restent l'autorité d'égalité.
|
||||
|
||||
## Pagination RAW transaction
|
||||
|
||||
@@ -181,4 +192,6 @@ La crate ne contient :
|
||||
- [`../../docs/plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md`](../../docs/plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md) — design `RawTransaction` ;
|
||||
- [`../../docs/validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md`](../../docs/validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md) — validation `RawTransaction` ;
|
||||
- [`../../docs/plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md`](../../docs/plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md) — design `RawAccountState` et complétude RAW ;
|
||||
- [`../../docs/validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md`](../../docs/validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md) — validation `RawAccountState` et conformance RAW.
|
||||
- [`../../docs/validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md`](../../docs/validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md) — validation `RawAccountState` et conformance RAW ;
|
||||
- [`../../docs/plans/038-V0_3_16_RAW_RESILIENCE_CONFLICT_PLAN.md`](../../docs/plans/038-V0_3_16_RAW_RESILIENCE_CONFLICT_PLAN.md) — V003, convergence et conflit durable ;
|
||||
- [`../../docs/validation/033-V0_3_16_RAW_RESILIENCE_CONFLICT.md`](../../docs/validation/033-V0_3_16_RAW_RESILIENCE_CONFLICT.md) — validation `0.3.16`, concurrence/rollback et live PostgreSQL 17.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: crates/ksp-store-postgres-lib/USAGE.md -->
|
||||
<!-- version: 11 -->
|
||||
<!-- version: 12 -->
|
||||
|
||||
# Utilisation de ksp-store-postgres-lib
|
||||
|
||||
@@ -155,7 +155,7 @@ async fn persist_acquisition(
|
||||
}
|
||||
```
|
||||
|
||||
L'opération est atomique : le canonique et son observation initiale sont tous deux durables ou aucun ne l'est. Une identité déjà présente avec un contenu identique est idempotente ; un contenu divergent retourne `PostgresBackendErrorKind::Conflict` sans overwrite silencieux.
|
||||
L'opération est atomique : variante reçue, observation, mapping observation->variante, selector/projection éventuels et conflict case sont tous durables ou aucun ne l'est. Une identité déjà présente avec un contenu exact est idempotente. Une divergence conservable retourne un succès `RawAcquisitionWriteOutcome` dont `transaction_variant()` vaut `QuarantinedConflict`; le canonique n'est pas écrasé. Une représentation strictement plus complète selon la seule preuve `logMessages` admise peut retourner `PromotedCompatibleMoreComplete` et promouvoir atomiquement le selector/projection. Les conflits d'observation directe et autres contrats legacy peuvent encore produire `PostgresBackendErrorKind::Conflict`.
|
||||
|
||||
Pour un tombstone purgé compatible, le mode `Normal` ne restaure pas le payload. `ForceRehydrate` doit être demandé explicitement pour rétablir un payload `Full`.
|
||||
|
||||
@@ -289,4 +289,4 @@ fn classify(error: &ksp_store_postgres_lib::PostgresBackendError) {
|
||||
|
||||
Le backend ne lit aucune variable d'environnement et ne possède aucune sélection de target Config. Les applications, jobs et workers doivent normalement passer par `ksp-store-lib`.
|
||||
|
||||
Les dix capabilities RAW communes sont implémentées par ce backend. Les décisions de batch, priorité, backlog, scheduling et policy de rétention restent hors de sa responsabilité ; aucune rétention/archivage/purge account n'est fournie.
|
||||
Les quatorze capabilities RAW communes sont implémentées par ce backend, dont les quatre capabilities d'inspection entity/observation. Les décisions de batch, priorité, backlog, scheduling et policy de rétention restent hors de sa responsabilité ; aucune rétention/archivage/purge account n'est fournie.
|
||||
|
||||
Reference in New Issue
Block a user