WIP feat(db+indexer): certifications
@librelois Voici un début.
- J'ai dû un peu modifier
gen_next_wot_id
car les deux premiers IDs générés étaient0
(les tests ne généraient qu'une seule identité donc ça ne se voyait pas). - J'ai aussi eu quelques problèmes de traits avec le schéma de db, donc j'ai dû créer des types wrappers pour les valeurs. Il voulait qu'ils implémentent
zerocopy::{AsBytes, FromBytes}
(j'ai réussi à faire ça uniquement avec#[repr(packed)]
) etDefault
. Les contraintes pourX
semblent être différentes si la valeur estX
ouVec<X>
par exemple, c'est bizarre. - À propos de
WotId
: Est-il judicieux de stocker desusize
en db ? Ça peut causer des problèmes si on change d'architecture. - J'ai un panic dans le test
test_update_certifications
: (peut-être à cause du#[repr(packed)]
?)
panicked at 'source slice length (33) does not match destination slice length (32)'
stack backtrace:
0: rust_begin_unwind
at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/panicking.rs:92:14
2: core::slice::<impl [T]>::copy_from_slice::len_mismatch_fail
at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/slice/mod.rs:3041:13
3: core::slice::<impl [T]>::copy_from_slice
at /home/tuxmain/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:3048:13
4: <duniter_gva_db::values::PublicKeyDb as kv_typed::from_bytes::FromBytes>::from_bytes
at /home/tuxmain/Documents/projets/duniter-gva/db/src/values.rs:75:9
5: <kv_typed::backend::memory::MemCol as kv_typed::backend::BackendCol>::get::{{closure}}::{{closure}}
at /home/tuxmain/.cargo/git/checkouts/duniter-core-11cd823ec7c898cf/56dd979/tools/kv_typed/src/backend/memory.rs:104:30
6: core::option::Option<T>::map
at /home/tuxmain/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:487:29
7: <kv_typed::backend::memory::MemCol as kv_typed::backend::BackendCol>::get::{{closure}}
at /home/tuxmain/.cargo/git/checkouts/duniter-core-11cd823ec7c898cf/56dd979/tools/kv_typed/src/backend/memory.rs:102:13
8: <kv_typed::key::U64BE as kv_typed::as_bytes::AsBytes>::as_bytes
at /home/tuxmain/.cargo/git/checkouts/duniter-core-11cd823ec7c898cf/56dd979/tools/kv_typed/src/as_bytes.rs:81:17
9: <kv_typed::backend::memory::MemCol as kv_typed::backend::BackendCol>::get
at /home/tuxmain/.cargo/git/checkouts/duniter-core-11cd823ec7c898cf/56dd979/tools/kv_typed/src/backend/memory.rs:101:9
10: kv_typed::transactional_write::TxColRw<BC,E>::get
at /home/tuxmain/.cargo/git/checkouts/duniter-core-11cd823ec7c898cf/56dd979/tools/kv_typed/src/transactional_write.rs:76:38
11: duniter_gva_indexer::certifications::update_certifications
at ./src/certifications.rs:41:38
...
- Dans
db
, certains noms sont préfixés pargva
, d'autres non. Puisqu'on est déjà dansduniter-gva
je choisis de ne pas le faire, mais ça pourrait être harmonisé.
Voilà il y a des TODO un peu partout où j'ai des doutes, et je me lancerai dans le revert quand les tests de l'apply passeront.
Edit: Chose étonnante, le pipeline a une erreur de compilation, alors que chez moi ça compile bien. (je suis bien en stable x86_64 1.52.1)
Merge request reports
Activity
J'ai dû un peu modifier
gen_next_wot_id
car les deux premiers IDs générés étaient0
(les tests ne généraient qu'une seule identité donc ça ne se voyait pas).Sauf que tu ne l'as pas modifiée correctement, je viens de le faire, rebase toi :)
J'ai aussi eu quelques problèmes de traits avec le schéma de db, donc j'ai dû créer des types wrappers pour les valeurs. Il voulait qu'ils implémentent zerocopy::{AsBytes, FromBytes} (j'ai réussi à faire ça uniquement avec #[repr(packed)]) et Default. Les contraintes pour X semblent être différentes si la valeur est X ou Vec par exemple, c'est bizarre.
Non c'est normal et voulu, je voulais que les trait AsBytes et FromBytes soit implémentés par tout ce qui peut se représenter en slice d'éléments zerocopiables, la conséquences c'est qu'il faut créer un wrapper pour ce qui se représente en slice d'éléments non-zerocopiables.
Il ne faut pas utiliser
#[repr(packed)]
, c'est marqué je sais plus où que cette annotation pose des problèmes, il est d'ailleurs prévu pour une future version de Rust qu'utiliser cette annotation ne puisse se faire que dans un bloc unsafe. Bref, annotation à bannir, on en à pas besoin :)À propos de WotId: Est-il judicieux de stocker des usize en db ? Ça peut causer des problèmes si on change d'architecture.
Non ça ne peut pas car j'ai implémenté les traits Serialize et Deserialize à la main pour que WotId soit sérialisé en u32.
J'ai un panic dans le test test_update_certifications: (peut-être à cause du #[repr(packed)] ?)
Probablement, essaye déjà de retirer cette annotation :)
Dans db, certains noms sont préfixés par gva, d'autres non. Puisqu'on est déjà dans duniter-gva je choisis de ne pas le faire, mais ça pourrait être harmonisé.
Il y a une raison derrière le fait que certaines clés ou valeurs sont préfixées par Gva: le risque de confusion. On préfixe si on sait qu'une valeur au nom similaire peut exister ailleurs. Par exemple, la notion d'identité existe dans la db BcV2, mais elle n'a pas le même but (vérif globale vs besoin des clients) donc pas les mêmes données.
Chose étonnante, le pipeline a une erreur de compilation, alors que chez moi ça compile bien.
Rien d'étonnant, compile avec
--all-features
et tu auras l'erreur en local ;)Je n'ai pas encore lu ton code, j'attends que te traite déjà ces premiers retours :)