こんにちは、
prefix_iterator
、オプションで宣言したもの( set_prefix_extractor
)よりも長いプレフィックスを付けた場合。
エラーは発生せず、プレフィックスの残りの部分も無視されません。Fromとともにプレフィックスのように動作します。
このような:
set_prefix_extractor(len)
myp = &[1u8; len+1];
prefix(myp[..len]) + From(myp)
そして実際の実例:
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);
}
これにより、次の結果が出力されます。
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]
したがって、最初のバイトは実際のプレフィックスのように動作します(完全に一致します)が、残りはプレフィックスでも無視されるものでもありません。これらは「From」として使用されます(これは[0,0で始まるすべてを無視することがわかります) ]ただし、[0,2]のような大きなバイトが含まれます)
これは望ましい動作ですか、それともバグですか?
あなたが見ている振る舞いは、コアライブラリがどのように実装されているかによるものだと思います。 これが設計によるものなのか、「未定義の動作」なのかはわかりません。
@elichai終了しますか、これはこの言語バインディングの問題だと思いますか?
うーん、私は実際にそれがC ++コードに存在するかどうかをチェックしなかったので、idk。
時間があるときにすぐに確認するかもしれません(C ++開発者ではありません)
@iSynapticこれが別の問題に値するかどうかわからない、
write_batchのput
関数には、 try!
は含まれていませんが、結果が返されます。
これは意図されたものですか? どうして?
https://github.com/rust-rocksdb/rust-rocksdb/blob/master/src/db.rs#L1147
@elichaiエラーの可能性は実装の詳細ではないため、これは意図された動作だと思います。 将来的には、ユーザー向けAPIを変更せずに、この内部実装を変更できるようになります
@elichai prefix_iterator
が奇妙に動作することに同意しますが、設計どおりです。 #254では、動作を検証し、動作を説明するコメントを含むテストを追加しました(以下に引用)。 私が望む振る舞いに基づいて、おそらく通常のイテレータを使用して、独自のReadOptions
を提供する必要があります。 これは#253で有効になっています。
説明:
db.prefix_iterator
は、prefix
全体に一致する最初のキーを探すための基礎となるオプションを設定します。 そこから、イテレータは、key
から抽出されたプレフィックスが、prefix
から抽出されたプレフィックスと一致する限り、ペアの読み取りを続行します。
@vitvakatu @aleksussイテレータを構築し、可能な限り単純化するすべての関数を確認する必要があると思います。少し混乱します。 私にはいくつかのアイデアがあり、PRをまとめることができます。