Rust-rocksdb: O prefixo iterador se comporta de maneira estranha

Criado em 8 nov. 2018 · 6Comentários · Fonte: rust-rocksdb/rust-rocksdb

Oi,
Se você der a prefix_iterator um prefixo mais longo do que o que você declarou em Opções ( set_prefix_extractor ).
Você não obtém um erro e ele não ignora o resto do prefixo, ele se comporta como um prefixo junto com um De.
como isso:

set_prefix_extractor(len)
myp = &[1u8; len+1];
prefix(myp[..len]) + From(myp)

E um exemplo real de trabalho:

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);
}

Isso imprimirá estes resultados:

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]

Portanto, o primeiro byte se comporta como um prefixo real (fornecendo uma correspondência exata), mas o resto não é um prefixo nem ignorado, eles estão sendo usados como um "De" (você pode ver que isso ignora tudo que começa com [0,0 ] mas inclui bytes maiores como [0,2])

Este é o comportamento desejado ou é um bug?

bug

Fonte

elichai

Todos 6 comentários

Suspeito que o comportamento que você está vendo é devido à forma como a biblioteca central é implementada. Não tenho certeza se isso ocorre por design ou "comportamento indefinido".

iSynaptic em 19 nov. 2018

👍1

@elichai Ok para fechar ou você acha que isso é um problema com esta ligação de linguagem?

iSynaptic em 29 nov. 2018

hmm Na verdade eu não verifiquei se ele existe no código C ++, então idk.
Talvez eu verifique logo, quando tiver tempo (não um dev C ++)

elichai em 9 dez. 2018

@iSynaptic Não tenho certeza se isso merece um problema separado,
As funções put de write_batch não contêm try! e ainda assim retornam um resultado.
Isso é intencional? porque?
https://github.com/rust-rocksdb/rust-rocksdb/blob/master/src/db.rs#L1147

elichai em 9 dez. 2018

@elichai acho que é o comportamento pretendido, já que nenhuma chance de erros é um detalhe de implementação. No futuro, poderemos alterar essa implementação interna sem alterar a API voltada para o usuário

vitvakatu em 10 dez. 2018

👍1

@elichai Eu agora concordo que prefix_iterator se comporta de maneira estranha, mas conforme projetado. No # 254, adicionei um teste que valida o comportamento e inclui um comentário explicando o comportamento (citado abaixo). Com base no comportamento que eu _penso_ que você deseja, você provavelmente deve usar um iterador regular e fornecer seu próprio ReadOptions . Isso está habilitado em # 253.

Explicação : db.prefix_iterator define as opções subjacentes para buscar a primeira chave que corresponde a prefix inteiro . A partir daí, o iterador continuará a ler pares, desde que o prefixo extraído de key corresponda ao prefixo extraído de prefix .

@vitvakatu @aleksuss Acho que precisamos dar uma olhada em todas as funções que constroem iteradores e simplificá-los o máximo possível - elas são um pouco confusas. Tenho algumas ideias e posso montar um RP.

iSynaptic em 3 fev. 2019

Esta página foi útil?

0 / 5 - 0 avaliações