Rust-rocksdb: Der Präfix-Iterator verhält sich komisch

Erstellt am 8. Nov. 2018 · 6Kommentare · Quelle: rust-rocksdb/rust-rocksdb

Hallo,
Wenn Sie dem prefix_iterator ein längeres Präfix geben als in den Optionen angegeben ( set_prefix_extractor ).
Sie erhalten keinen Fehler und der Rest des Präfixes wird nicht ignoriert. Es verhält sich wie ein Präfix zusammen mit einem Von.
so was:

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

Und ein aktuelles Arbeitsbeispiel:

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

Dadurch werden die folgenden Ergebnisse gedruckt:

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]

Das erste Byte verhält sich also wie ein echtes Präfix (was eine genaue Übereinstimmung ergibt), aber der Rest ist weder ein Präfix noch wird es ignoriert. Sie werden als "Von" verwendet (Sie können sehen, dass dies alles ignoriert, was mit [0,0 beginnt) ] enthält aber größere Bytes wie [0,2])

Ist das das gewünschte Verhalten oder ist das ein Fehler?

bug

Quelle

elichai

Alle 6 Kommentare

Ich vermute, dass das Verhalten, das Sie sehen, darauf zurückzuführen ist, wie die Kernbibliothek implementiert ist. Ich bin mir nicht sicher, ob dies beabsichtigt oder "undefiniertes Verhalten" ist.

iSynaptic am 19. Nov. 2018

👍1

@elichai Okay zum Schließen oder denkst du, dass dies ein Problem mit dieser Sprachbindung ist?

iSynaptic am 29. Nov. 2018

hmm ich habe eigentlich nicht überprüft ob es im C ++ Code existiert, also idk.
Vielleicht werde ich bald nachsehen, wenn ich Zeit habe (kein C ++ - Entwickler)

elichai am 9. Dez. 2018

@iSynaptic Nicht sicher, ob dies ein separates Problem verdient,
Die put -Funktionen von write_batch enthalten keine try! und geben dennoch ein Ergebnis zurück.
Ist das beabsichtigt? Warum?
https://github.com/rust-rocksdb/rust-rocksdb/blob/master/src/db.rs#L1147

elichai am 9. Dez. 2018

@elichai Ich denke, es ist beabsichtigtes Verhalten, da keine

vitvakatu am 10. Dez. 2018

👍1

@elichai Ich stimme jetzt zu, dass sich prefix_iterator seltsam verhält, aber wie geplant. In # 254 habe ich einen Test hinzugefügt, der das Verhalten validiert und einen Kommentar enthält, der das Verhalten erklärt (siehe unten). Basierend auf dem Verhalten, von dem ich denke, dass Sie es möchten, sollten Sie wahrscheinlich einen regulären Iterator verwenden und Ihr eigenes ReadOptions bereitstellen. Dies ist in # 253 aktiviert.

Erläuterung : db.prefix_iterator legt die zugrunde liegenden Optionen für die Suche nach dem ersten Schlüssel fest, der mit dem gesamten prefix übereinstimmt. Von dort aus liest der Iterator weiterhin Paare, solange das aus key extrahierte Präfix mit dem aus prefix extrahierten Präfix übereinstimmt.

@vitvakatu @aleksuss Ich denke, wir müssen uns alle Funktionen ansehen, die Iteratoren konstruieren, und sie so weit wie möglich vereinfachen - sie sind etwas verwirrend. Ich habe einige Ideen und kann eine PR zusammenstellen.

iSynaptic am 3. Feb. 2019

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Rust-rocksdb: Der Präfix-Iterator verhält sich komisch

Alle 6 Kommentare

Verwandte Themen