Rust-rocksdb: El iterador de prefijo se comporta de manera extraña
Hola,
Si le da a prefix_iterator un prefijo más largo que el que declaró en Opciones ( set_prefix_extractor ).
No obtiene un error y no ignora el resto del prefijo, se comporta como un prefijo junto con un De.
como esto:
set_prefix_extractor(len)
myp = &[1u8; len+1];
prefix(myp[..len]) + From(myp)
Y un ejemplo de trabajo real:
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);
}
Esto imprimirá estos 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]
Entonces, el primer byte se comporta como un prefijo real (dando una coincidencia exacta), pero el resto no es un prefijo ni se ignora, se usan como un "De" (puede ver que esto ignora todo lo que comienza con [0,0 ] pero incluye bytes más grandes como [0,2])
¿Es este el comportamiento deseado o es un error?
elichai
Todos 6 comentarios
Sospecho que el comportamiento que está viendo se debe a cómo se implementa la biblioteca principal. No estoy seguro si esto es por diseño o "comportamiento indefinido".
iSynaptic
en 19 nov. 2018
@elichai ¿ Está bien cerrar o cree que esto es un problema con este enlace de idioma?
iSynaptic
en 29 nov. 2018
hmm, en realidad no verifiqué si existe en el código C ++, así que idk.
Tal vez lo verifique pronto cuando tenga tiempo (no un desarrollador de C ++)
elichai
en 9 dic. 2018
@iSynaptic No estoy seguro de si esto merece un problema por separado,
Las funciones put de write_batch no contienen ningún try! y, sin embargo, devuelven un resultado.
¿Es esto intencionado? ¿Por qué?
https://github.com/rust-rocksdb/rust-rocksdb/blob/master/src/db.rs#L1147
elichai
en 9 dic. 2018
@elichai Creo que es el comportamiento previsto, ya que no hay posibilidad de errores en los detalles de implementación. En el futuro, podremos cambiar esta implementación interna sin cambiar la API de cara al usuario.
vitvakatu
en 10 dic. 2018
@elichai Ahora estoy de acuerdo en que prefix_iterator comporta ReadOptions . Esto está habilitado en # 253.
Explicación :
db.prefix_iteratorestablece las opciones subyacentes para buscar la primera clave que coincida con elprefixcompleto . A partir de ahí, el iterador continuará leyendo pares siempre que el prefijo extraído dekeycoincida con el prefijo extraído deprefix.
@vitvakatu @aleksuss Creo que debemos echar un vistazo a todas las funciones que construyen iteradores y simplificarlas tanto como sea posible; son un poco confusas. Tengo algunas ideas y puedo armar un PR.
iSynaptic
en 3 feb. 2019
Temas relacionados
valeriansaliou
·
4Comentarios
spacejam
·
3Comentarios
zach-schoenberger
·
5Comentarios
rrichardson
·
7Comentarios
iSynaptic
·
5Comentarios