Application: gvSIG desktop

He estado mirando esto y efectivamente estamos replicando las features al navegar por la tabla. Las posibles soluciones que veo son:

- No replicar las geometrías, pero entonces habrá que mostrar una casilla vacía si el usuario activa la opción de ver también la geometría en la tabla (se le muestra como WKT). Se podría mostrar solo si es punto, por ejemplo.

- Rehacer el paginador para que no haga falta replicar las geometrías (es decir, quizá no usar un fast iterator sino un iterator normal?)

- Tener en cuenta si se están mostrando o no la geometría en la tabla para decidir si se intenta replicar o no la geometría. Tal como está hecho ahora. me parece que no hay acceso a ese dato desde el paginador.

Una solución que al menos a nivel usuario veo viable:
- Cuando el usuario no activa el campo geometría (que por defecto no está visible) que no lo tenga en cuenta. Cuando lo active que recargue la tabla con dicho campo. Aquí ya en shp muy gordos, con miles de nodos, como el que comentaba César, dejamos en el usuario la decisión de abordar esto y la lentitud que provoca. Pero a priori el 99% de los usuarios no van a necesitar activar ese campo.
- A tener en cuenta, cuando la capa entre en edición, esa recarga con el campo geometría entiendo que debería realizarse.

Bueno, despues de pensar bastante creo que he hecho algo que parece solventar el problema.

El resumen seria...
Cuando intenta cargar las features para visualizarlas en la tabla solo carga los valores de la feature que estan visibles en la tabla, es decir los atributos de las columnas que no estan visibles pasa de cargarlos.
Salvo que se este en edicion, en cuyo caso se cargan todos los atributos de la feature, esten o no visibles, ya que son necesarios por si se tuviese que actualizar la feature.

El como.
El problema es que necesitamos tener la feature completa. No podemos quitarle columnas ya que eso podria provocar efectos extraños.
Lo que he hecho es añadir en el FeatureQuery la posibilidad de especificar que algunos atributos de la feature son constantes, con lo que no es preciso cargarlos de disco, y simplemente se les asigna el valor por defecto que tenga especificado el atributo. Y el modelo de la tabla se encarga de actualizar estos parametros del query con los campos que no estan visibles, todo esto solo si no estamos en edicion. Si la tabla esta en edicion, se le dice en el query que cargue la feature normalmente.

Como efecto secundario no deseado de esto, lo que sucede es que si vamos a propiedades de la tabla y marcanos o desmarcamos el check de visibilidad de una columna, se recargara la pagina corriente de la tabla entera de nuevo (atualmente son 100 registros por pagina).

He adjuntado al ticket el diagrama de clases que me he hecho sobre el modelo de clases de la tabla para aclararme, mas que nada por no tirarlo sin mas.
No es un modelo riguroso en ningun sentido, solo tiene lo justo para poder aclararme yo, y con la nomenclatura que me venia bien para esto.

Creo que funciona mejor que antes ya que no carga en las features que tiene cacheadas por pagina los campos que no se ven (por defecto, la geometria), aunque ahora habria que repasar cada proveedor de datos para ver si puede comprobar que campos debe cargar en memoria o no, ya que los proveedores de datos siguen cargando los datos que no se ven, aunque luego estos no se almacenen en la feature.

Bien, pues retocar el proveedor de shape para que no cargue la geometria si no era necesario ha sido bastante sencillo y la diferencia en prestaciones con la capa "World_EEZ_v7_2012_HR" es sustanciosa.