Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.0.3-pre.010

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 13:05:50 +02:00
parent 2dada316c1
commit 5e169af906
16 changed files with 283 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Data, Materialization et Store
@@ -19,7 +19,7 @@ Il définit les frontières durables de données KSP et précise :
- sémantique des notifications de données persistées ;
- stabilité différente entre niveaux structurants et projections spécialisées.
Cette tranche ne détaille pas encore le lifecycle complet, batching, concurrence ou supervision des workers/jobs. Ces sujets sont déplacés vers `pre.007`.
Le lifecycle complet, batching, concurrence, backlog et reprise des workers/jobs sont détaillés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
## Nomenclature des niveaux durables
@@ -555,7 +555,7 @@ Il ne doit pas être nécessaire de refaire toute la chaîne lorsqu'un niveau in
Les replays sont des **jobs bornés**, pas des modes cachés des workers live.
Les noms exacts des futurs jobs de replay sont reportés à `pre.007`.
Les jobs de replay retenus sont `ksp-job-replay-core`, `ksp-job-replay-generic-materialization` et `ksp-job-replay-domain-projection`.
# Notifications de données persistées
@@ -649,7 +649,7 @@ broker externe
`ksp-store-lib` peut fournir PostgreSQL LISTEN/NOTIFY comme mécanisme de référence si cela répond au premier besoin.
Le choix détaillé des mécanismes, reprise, batching et multi-process est reporté à `pre.007`.
Le mécanisme initial de référence et la reprise opérationnelle sont détaillés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
# Acquisition live et backfill
@@ -690,7 +690,7 @@ Chaque worker :
- écrit seulement le niveau durable dont il est propriétaire ;
- ne transforme pas silencieusement plusieurs frontières en une étape monolithique.
Le détail lifecycle, concurrence, batching, cursors, checkpoints et hot reconfiguration est reporté à `pre.007`.
Le lifecycle, la concurrence, les cursors/checkpoints et la hot reconfiguration sont détaillés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
# Projections de trading et autres domaines
@@ -722,11 +722,12 @@ La première implémentation Store devra encore fixer :
- conversion u64/slot/PostgreSQL ;
- stratégie des migrations initiales.
`pre.007` doit préciser :
Les sujets opérationnels worker/job ont été précisés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
- lifecycle des quatre workers ;
- jobs de replay ;
- checkpoint/backlog ;
- batching/concurrence ;
- mécanisme de notification de référence ;
- processus/IPC selon les managers retenus.
Restent à définir à l'implémentation :
- schémas SQL et contraintes exactes ;
- format concret des DTO D1/D2/D3/D4 ;
- claim/lease PostgreSQL ;
- contexte des projectors stateful ;
- mécanisme IPC des managers de services autonomes.