Rust-rocksdb: L'itérateur de préfixe se comporte bizarrement
Salut,
Si vous donnez au prefix_iterator un préfixe plus long que ce que vous avez déclaré dans Options ( set_prefix_extractor ).
Vous n'obtenez pas d'erreur et il n'ignore pas le reste du préfixe, il se comporte comme un préfixe avec un From.
comme ça:
set_prefix_extractor(len)
myp = &[1u8; len+1];
prefix(myp[..len]) + From(myp)
Et un exemple de travail réel:
let prefix_extractor = rocksdb::SliceTransform::create_fixed_prefix(1);
let mut opts = Options::default();
opts.create_if_missing(true);
opts.set_prefix_extractor(prefix_extractor);
let db = DB::open(&opts, &tempdir).unwrap();
db.put(&[0,0,0,0], &[0,0,0,0]).unwrap();
db.put(&[0,0,0,1], &[0,0,0,1]).unwrap();
db.put(&[0,1,0,1], &[0,1,0,1]).unwrap();
db.put(&[0,1,1,1], &[0,1,1,1]).unwrap();
db.put(&[0,1,2,1], &[0,1,2,1]).unwrap();
db.put(&[2,0,0,0], &[2,0,0,0]).unwrap();
db.put(&[2,2,2,2], &[2,2,2,2]).unwrap();
let me = db.prefix_iterator(&[0,1,0]);
for (key, value) in me {
println!("Saw {:?} {:?}", key, value);
}
Cela imprimera ces résultats:
Saw [0, 1, 0, 1] [0, 1, 0, 1]
Saw [0, 1, 1, 1] [0, 1, 1, 1]
Saw [0, 1, 2, 1] [0, 1, 2, 1]
Ainsi, le premier octet se comporte comme un vrai préfixe (donnant une correspondance exacte), mais le reste n'est ni un préfixe ni ignoré, ils sont utilisés comme un "De" (vous pouvez voir que cela ignore tout ce qui commence par [0,0 ] mais inclut des octets plus gros comme [0,2])
Est-ce le comportement recherché ou est-ce un bogue?
elichai
Tous les 6 commentaires
Je soupçonne que le comportement que vous voyez est dû à la façon dont la bibliothèque principale est implémentée. Je ne suis pas sûr que ce soit par conception ou "comportement indéfini".
iSynaptic
le 19 nov. 2018
@elichai OK pour fermer ou pensez-vous que c'est un problème avec cette liaison de langue?
iSynaptic
le 29 nov. 2018
hmm Je n'ai en fait pas vérifié s'il existe dans le code C ++, donc idk.
Peut-être que je vérifierai bientôt quand j'aurai le temps (pas un développeur C ++)
elichai
le 9 déc. 2018
@iSynaptic Je ne sais pas si cela mérite un problème séparé,
Les fonctions put de write_batch ne contiennent aucun try! et pourtant elles renvoient un résultat.
Est-ce voulu? Pourquoi?
https://github.com/rust-rocksdb/rust-rocksdb/blob/master/src/db.rs#L1147
elichai
le 9 déc. 2018
@elichai Je pense que c'est un comportement prévu, car aucune chance d'erreur n'est le détail de l'implémentation. À l'avenir, nous pourrons modifier cette implémentation interne sans modifier l'API destinée aux utilisateurs
vitvakatu
le 10 déc. 2018
@elichai Je suis maintenant d'accord que prefix_iterator se comporte bizarrement, mais comme prévu. Au n ° 254, j'ai ajouté un test qui valide le comportement et inclut un commentaire expliquant le comportement (cité ci-dessous). En fonction du comportement que je pense que vous voulez, vous devriez probablement utiliser un itérateur régulier et fournir votre propre ReadOptions . Ceci est activé dans # 253.
Explication :
db.prefix_iteratordéfinit les options sous-jacentes pour rechercher la première clé qui correspond à la totalité deprefix. À partir de là, l'itérateur continuera à lire les paires tant que le préfixe extrait dekeycorrespond au préfixe extrait deprefix.
@vitvakatu @aleksuss Je pense que nous devons jeter un œil à toutes les fonctions qui construisent des itérateurs et les simplifier autant que possible - elles sont un peu déroutantes. J'ai quelques idées et je peux mettre en place un PR.
iSynaptic
le 3 févr. 2019
Questions connexes
iSynaptic
·
12Commentaires
valeriansaliou
·
4Commentaires
rrichardson
·
7Commentaires
iSynaptic
·
31Commentaires
zach-schoenberger
·
7Commentaires