Skip to content
Snippets Groups Projects

WIP feat(db+indexer): certifications

Open Pascal Engélibert requested to merge tuxmain/duniter-gva:certifications into master

@librelois Voici un début.

  • J'ai dû un peu modifier gen_next_wot_id car les deux premiers IDs générés étaient 0 (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)]) et Default. Les contraintes pour X semblent être différentes si la valeur est X ou Vec<X> par exemple, c'est bizarre.
  • À propos de WotId: Est-il judicieux de stocker des usize 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 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é.

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. :smiley:

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)

Edited by Pascal Engélibert

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Pascal Engélibert changed the description

    changed the description

  • J'ai dû un peu modifier gen_next_wot_id car les deux premiers IDs générés étaient 0 (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 :)

Please register or sign in to reply
Loading