<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">El 5 de junio de 2016, 10:53, Francisco Puga <span dir="ltr">&lt;<a href="mailto:fpuga@icarto.es" target="_blank">fpuga@icarto.es</a>&gt;</span> escribió:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hola Joaquín,<div><br></div><div>Gracias por el post es muy ilustrativo.</div><div><br></div><div>La aproximación que estoy tomando para hacer la migración es tratar de hacer una traducción 1 a 1, creando incluso clases auxiliares que me provean de un comportamiento similar a la v1.x. Una vez que consiga tenerlo funcionando mi idea es refactorizar hacia una estructura más acorde a la v2. Igual me equivoco pero hice una prueba rápida e intentar migrar directamente a una estructura como la v2 introduce demasiados bugs. De la otra forma puedo tenerlo funcionando relativamente rápido y en función del tiempo disponible priorizar tareas.</div><div><br></div></div></blockquote><div><br></div><div>Desde el proyecto aconsejamos se siga una estructura de proyecto; pero en principio, mientras no hayan otros condicionantes, es solo eso, un consejo de buenas practicas. Eso si, la estructura de proyecto que aconsejamos requiere un esfuerzo inicial en el analisis, asi como entender que es cada pieza para poder dejar las cosas en su sitio. La experiencia es que a medio plazo el codigo es mucho mas facil de mantener, pero en general para pasar de gvSIG 1 a gvSIG 2 muy poco del codigo es reutilizable. La aproximacion que propones no te la aconsejo. Hemos tenido muy males experiencias con ella. No pienses que despues de que tengas tu proyecto funcionando en gvSIG 2 te va a ser mas facil migrar a la estructura de proyecto nuevo. No suele ser asi, sigue siendo igual de dificil y ya has invertido un monton de horas. Decide si vas o no a seguir la nueva estructura de proyecto y sigue adelante con la decision que tomes sin pensar que luego ya lo cambiaras. Al final el coste de cambiarlo es muy alto.<br><br></div><div>Sin pensarlo mucho, un cambio si que te aconsejo que te plantees. Sustituye todos los accesos aleatorios a datos que tengas por secuenciales siempre que se pueda. Esto no tiene nada que ver con la estructura del proyecto y te iran mucho mejor las cosas.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Tendría que revisar un poco el código pero por lo que explicas en el post entiendo que con FeaturePagingHelper me traigo a memoria un número de features igual al del tamaño de página y cuando pido una feature fuera de la página actual hago otra petición (a bd o lo que sea).</div></div></blockquote><div><br>Correcto ,se mantiene en memoria una lista de tantas features como hayas indicado en el tamaño de pagina, y cuando le pides una feature que se salga de la pagina cargada, calcula en que pagina esta la que le has pedido y carga esa pagina.  Deberas mantener un equilibrio en lo que es el tamaño de pagina. Paginas muy grandes consumen mucha memoria y provocan parones grandes cuando se provoca un fallo de pagina, con lo que el acceso no es fluido. Paginas muy pequeñas, consumen poca memoria y se cargan muy rapido, pero provocan muchos fallos de pagina, con lo que el recorrido es lento. Si no recuerdo mal, el documento tabla tiene un tamaño de pagina de 100 features, por si te sirve para hacerte una idea.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Lo que tengo dudas es en el acceso al FeatureSet. Cuando se hace la petición a la bd ¿cuando se crea el fastIterator?</div></div><div class="gmail_extra"><div><div class="h5"><br></div></div></div></blockquote><div>En el proveedor de PostgreSQL se crea el ResultSet de JDBC cuando se le pide al FeatureSet el iterador. En general supongo que eso sera valido para otros proveedores que extiendan del de JDBC como hace este.<br></div><div>Para los de fichero, cada cual hace lo que cree oportuno.<br><br></div><div>Cuidado con las ordenaciones y filtros en los proveedores de fichero, como el shp. Cuando se hace una ordenacion, con la implementacion actual, se cargan todos los datos en memoria. Y con un filtro, si esta en edicion, el orden de las features devueltas no siempre puede ser el mismo.<br><br></div><div>Un saludo<br></div><div>Joaquin<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div><div class="h5"><div class="gmail_quote">El 4 de junio de 2016, 15:10, Joaquin Jose del Cerro Murciano <span dir="ltr">&lt;<a href="mailto:jjdelcerro@gvsig.org" target="_blank">jjdelcerro@gvsig.org</a>&gt;</span> escribió:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>El 4 de junio de 2016, 12:52, Francisco Puga <span dir="ltr">&lt;<a href="mailto:fpuga@icarto.es" target="_blank">fpuga@icarto.es</a>&gt;</span> escribió:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hola,
<div><br></div><div>Estoy tratando de migrar código de la 1 a la 2. En la 1 era muy habitual acceder a una feature de la capa por posición con un código de este estilo:</div><div><br></div><div>int pos = 0;</div><div>FLyrVect lyr = null;</div><div>IFeature feature = lyr.getSource().getFeature(pos);<br></div><div><br></div><div>Cual sería la forma lógica de hacer esto en la 2. Ahora mismo estoy probando a acceder mediante un iterator inicializado a esa posición concreta, pero igual tiene más sentido con un FeatureQuery, ¿Podéis poner un ejemplo de como sería con el FeatureQuery?</div><div><br></div><div><div>public static FeatureReference getFeature(FeatureStore fs , long feature) {</div><div><span style="white-space:pre-wrap">        </span>FeatureReference ref = null;</div><div><span style="white-space:pre-wrap">        </span>FeatureSet featSet = null;</div><div><span style="white-space:pre-wrap">        </span>DisposableIterator fastIterator = null;</div><div><span style="white-space:pre-wrap">        </span>try {</div><div><span style="white-space:pre-wrap">                </span>featSet = fs.getFeatureSet();</div><div><span style="white-space:pre-wrap">                </span>fastIterator = featSet.fastIterator(feature);</div><div><span style="white-space:pre-wrap">                </span>Feature feat = (Feature) fastIterator.next();</div><div><span style="white-space:pre-wrap">                </span>ref = feat.getReference();</div><div><span style="white-space:pre-wrap">        </span>} catch (DataException e) {</div><div><span style="white-space:pre-wrap">                logger.error(e.getStackTrace(),e);</span></div><div><span style="white-space:pre-wrap">        </span>} finally {</div><div><span style="white-space:pre-wrap">                </span>DisposeUtils.dispose(fastIterator);</div><div><span style="white-space:pre-wrap">                </span>DisposeUtils.dispose(featSet);</div><div><span style="white-space:pre-wrap">        </span>}</div><div><span style="white-space:pre-wrap">        </span>return ref;</div><div>}</div></div><div><br></div></div></blockquote></span><div><br>Hola Francisco,<br>en lugar de contestarte aquí he preferido crear un pequeño articulo en el blog de gvSIG comentando sobre esto.<br><br>Puedes encontrar el articulo en:<br><br><a href="https://blog.gvsig.org/2016/06/04/accediendo-a-un-feature-por-posicion-en-gvsig-desktop-2-3-0/" target="_blank">https://blog.gvsig.org/2016/06/04/accediendo-a-un-feature-por-posicion-en-gvsig-desktop-2-3-0/</a><br><br>También te recomiendo que le eches un vistazo a: <br><br><a href="https://blog.gvsig.org/2015/04/21/recomendaciones-y-trucos-para-desarrollar-con-gvsig-2-1-1-recorriendo-datos/" target="_blank">https://blog.gvsig.org/2015/04/21/recomendaciones-y-trucos-para-desarrollar-con-gvsig-2-1-1-recorriendo-datos/</a><br><br>Espero que te sirva,  y no dudéis en preguntar las dudas, trataremos de contestar en cuanto podamos.<br><br>Un saludo<br>Joaquin<br><br><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Saludos. Gracias</div></div>
<br>_______________________________________________<br>
gvSIG_desarrolladores mailing list<br>
<a href="mailto:gvSIG_desarrolladores@listserv.gva.es" target="_blank">gvSIG_desarrolladores@listserv.gva.es</a><br>
Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección: <a href="https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores" rel="noreferrer" target="_blank">https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><br>-- <br><div data-smartmail="gmail_signature">--------------------------------------<br>Joaquin Jose del Cerro Murciano<br>Development and software arquitecture manager at gvSIG Team<br><a href="mailto:jjdelcerro@gvsig.com" target="_blank">jjdelcerro@gvsig.com</a><br><a href="mailto:jjdelcerro@gvsig.org" target="_blank">jjdelcerro@gvsig.org</a><br>gvSIG Association<br><a href="http://www.gvsig.com" target="_blank">www.gvsig.com</a><br><a href="http://www.gvsig.org" target="_blank">www.gvsig.org</a></div>
</font></span></div></div>
<br>_______________________________________________<br>
gvSIG_desarrolladores mailing list<br>
<a href="mailto:gvSIG_desarrolladores@listserv.gva.es" target="_blank">gvSIG_desarrolladores@listserv.gva.es</a><br>
Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección: <a href="https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores" rel="noreferrer" target="_blank">https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>Francisco Puga</div><div>iCarto | Innovación, Cooperación, Cartografía y Territorio S.L.</div><div><a href="http://www.icarto.es/" target="_blank">http://www.icarto.es/</a></div><div><br></div><div>c/ Rafael Alberti nº 13 – 1º D</div><div>15008 A Coruña</div><div>Galicia (Spain)</div><div><a href="tel:%2B34%20881927808" value="+34881927808" target="_blank">+34 881927808</a></div><div><br></div><div>Este correo electrónico contiene información estrictamente confidencial y es de uso exclusivo del destinatario, quedando prohibida a cualquier otra persona su revelación, copia, distribución, o el ejercicio de cualquier acción relativa a su contenido. Si ha recibido este mensaje por error, por favor conteste a su remitente mediante correo electrónico y proceda a borrarlo de su sistema.</div><div><br></div><div>Sus datos personales serán tratados de forma confidencial y no serán cedidos a terceros ajenos a ICARTO. En cualquier caso, podrá ejercer los derecho de oposición, acceso, rectificación y cancelación de acuerdo con lo establecido en la Ley Orgánica 15/99, de 13 de diciembre, de Protección de Datos de Carácter Personal dirigiéndose a Innovación, Cooperación, Cartografía e Territorio, SL. (ICARTO) en la dirección postal a C/ Rafael Alberti, nº 13, 1ºD, 15.008 – (A Coruña).</div></div></div>
</div>
<br>_______________________________________________<br>
gvSIG_desarrolladores mailing list<br>
<a href="mailto:gvSIG_desarrolladores@listserv.gva.es">gvSIG_desarrolladores@listserv.gva.es</a><br>
Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección: <a href="https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores" rel="noreferrer" target="_blank">https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--------------------------------------<br>Joaquin Jose del Cerro Murciano<br>Development and software arquitecture manager at gvSIG Team<br><a href="mailto:jjdelcerro@gvsig.com" target="_blank">jjdelcerro@gvsig.com</a><br><a href="mailto:jjdelcerro@gvsig.org" target="_blank">jjdelcerro@gvsig.org</a><br>gvSIG Association<br><a href="http://www.gvsig.com" target="_blank">www.gvsig.com</a><br><a href="http://www.gvsig.org" target="_blank">www.gvsig.org</a></div>
</div></div>