Duda rangos de iteración de `IsamNonClusteredIter`

[jtcaraball]

Hola! Tengo una pregunta cortita. Cual es el objetivo de pasar los limites del iterador (min y max) como instancias de Value en vez de su valor serializado que puede compararse directamente con el key de los records? Perdón si la pregunta es muy tonta pero me causa inseguridad sobre mi entendimiento del problema :sweat_smile:

[cirojas]

Se podría comparar directamente con el key de los records si solo se considerara soportar como key los enteros, u otros tipos de datos de tamaño fijo.

Al soportar también los string, donde la información del key no alcanza para un string de más de 8 bytes, es necesario hacer un chequeo adicional, y la forma de hacerlo en la tarea es comparando objetos de tipo Value.

[jtcaraball]

Quizás estoy entendiendo mal el enunciado. La idea es que los keys del indice correspondan al valor (truncado en el caso de strings largos) del atributo por el que se indexo no? Si es el caso la única forma de comparar el valor completo que tiene el atributo de la tupla sería cargándola desde la página (creo). Eso suena contraproducente :c

[cirojas]

Tienes razón, en la iteración hay que cargar la tupla desde el heapfile para poder comparar el valor. Pero cuando la tupla está en el rango deseado, igual es necesario cargar la tupla para escribirla en out, así que el trabajo adicional es sólo cuando cargas una tupla fuera del rango [min, max].

Tambien debo recordar que el objetivo de este proyecto es pedagógico, así que a veces no se toma la desición pensando en hacer lo más eficiente, sino que se pondera con la dificultad y complejidad que eso implica. Si quisiera tener el mejor índice no elegiría un ISAM, sino un B+tree, también tendría una implementación para cuando el key es un entero y otra distinta para cuando es un string. Adicionalmente, el heapfile sería más complicado y permitiría cargar un atributo sin tener que cargar el record completo.

[jtcaraball]

Eso aclara mis dudas. Muchas gracias!

[DiegoEmilio01]

Solo para ser mas claros todavía: si copararan keys en las hojas del índice y ciegamente retornan un record, podría causar errores poque las keys se truncan. Simplificando los tamaños, supongamos que en una hoja del índice están todas las tuplas cuyo primer atributo string calzan con la max key "12345678", eventualmente una record en el heapfile podría tener atributo "123456789" y no deben retornarlo. El comportamiento esperado es comparación por Value (que ya tiene programado dicho comportamiento).