<div dir="ltr">Hola, <br>primero un comentario y despues te voy comentando el resto entre lineas.<br>Una de las cosas que se ha intentado hacer en gvSIG 2, es separar mucho la implementacion de los APIs.<br>Uno no deberia enlacer (añadir a tu classpath de compilacion) ninguna implementacion. En terminos de maven, no deberiamos tener ninguna implementacion con un scope de "compile" (o sin scope que es lo mismo que compile).<br>No hay ningun compromiso en mantener entre versiones nada que se encuentre en un jar de implementacion, ya nos cuesta bastante intentar mantener el API y SPI. Esto implica no solo a las implementaciones de librerias, si no a las implementaciones de proveedores de datos.<br>Si mañana decidimos reimplementar el proveedor de postgreSQL, intentariamos mantener los parametros que definen el DataStoreParameters y el DataServerExplorerParameters, los que se exponen a traves del interface de DynObject, pero no nos molestariamos en mantener nada mas, ni nombres de paquetes ni nombres de clases, nada de la implementacion del proveedor. La aplicacion no precisa de ello para funcionar.<br><br>Asi que con esto en mente mi recomendacion es que nunca dependas de un jar de implementacion, simplemente procura no añadirlos nunca en tus proyectos maven como dependencias que no sean de runtime, o incluso no las añadas y asi seguro que eclipse no se te lia (eclipse solo tiene un classpath, y no uno para compilar y otro de runtime).<br><br>Dicho esto te voy comentando entre lineas.<br><div class="gmail_extra"><br><div class="gmail_quote">El 20 de junio de 2016, 13:38, Francisco Puga <span dir="ltr"><<a href="mailto:fpuga@icarto.es" target="_blank">fpuga@icarto.es</a>></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">Creo que no hice la pregunta correcta. Después de revisar la documentación me un par de dudas. Lo que quiero es cargar por código varias capas de una bd postgres.<div><br></div><div>Para ello hago algo de este estilo:</div><div><br></div><div><div>public DataStoreParameters getParams() throws DataException {</div><div> DataManager dataManager = DALLocator.getDataManager();</div><div><span style="white-space:pre-wrap"> </span>DataStoreParameters pgParameters = null;</div><div><span style="white-space:pre-wrap"> params</span> = dataManager.createStoreParameters(PostgreSQLStoreProvider.NAME);</div><div> params.setDynValue("host", SERVER);</div><div> params.setDynValue("port", PORT);</div><div><span style="white-space:pre-wrap"> </span>params.setDynValue("dbuser", USERNAME);</div><div><span style="white-space:pre-wrap"> </span>params.setDynValue("password", PASSWORD);</div><div><span style="white-space:pre-wrap"> params.setDynValue("dbname", DBNAME);</span></div><div>}</div></div><div><br></div></div></blockquote><div><br><br>Yo eliminaria la referencia a PostgreSQLStoreProvider.NAME y la sustituiria por una constante en tu proyecto.<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><div>public FLyrVect createLayer(String schema, String table) throws DataException, LoadLayerException {</div><div><span style="white-space:pre-wrap"> </span>MapContextManager mapContextManager = MapContextLocator.getMapContextManager();</div><div><span style="white-space:pre-wrap"> </span>DataStoreParameters params = (DataStoreParameters) getParams().getCopy();</div><div><span style="white-space:pre-wrap"> </span>FLayer layer = mapContextManager.createLayer(table, params);</div><div><span style="white-space:pre-wrap"> </span>return (FLyrVect) layer;</div><div>}</div></div></div></blockquote><div><br><br>En principio la idea parece correcta, pero le falta algo. Asi de memoria echo en falta que indiques la tabla que quieres abrir en los DataStoreParameters. Ten en cuenta que una capa siempre se crea a partir de un DataStore. El metodo createLayer que recibe un DataStoreParameters es simplemente un metodo de utilidad que se limita a crear el DataStore y luego con el crea la capa. Asi que los parametros deben ser todos los necesarios para crear el DataStore. El primer parametro, que has llamado "table", es el nombre de la capa en gvSIG, lo que devuelbe el "layer.getName()", y no como se llama la capa en la BBDD.<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>El MapContextManager.createLayer por debajo hace una llamada a:</div><div><br></div><div>DataStore dataStore=dataManager.createStore(storeParameters);<br></div><div><br></div><div>Entiendo que<b> si llamo dos veces al createStore / openStore del DataManage con los mismos datos básicos de la conexión a la bd (server, puerto, ...) no se crea una conexión nueva </b>si no que se reaprovecha la existente.</div></div></blockquote><div><br><br>Cada proveedor de acceso a datos hace de su capa un sayo. El de postgreSQL concretamente utiliza la libreria "commons-pool" de apache para gestionar las conexiones con la BBDD. No se si te refieres a esto. Cada vez que se precisa una conexion se pide al pool a traves del metodo getConnection de la clase BasicDataSource y cuando se termina de usar se cierra la conexion de forma que esta vuelve a estar disponible en el pool. Si tienes curiosidad sobre como evoluciona le pool puedes activar las trazas de acceso a JDBC/postgreSQL y te mostrara informacion en el log, bueno, esa y bastante mas. Puedes hacerlo tocando el fichero "log4j.properties" que encontraras en el raiz de la instalacion de gvSIG, y en el, en las lineas:<br><br>#<br># JDBC/PostgreSQL<br>log4j.logger.org.gvsig.fmap.dal.store.jdbc=INFO<br>log4j.logger.org.gvsig.fmap.dal.store.postgresql=INFO<br>log4j.logger.org.gvsig.exportto.swing.prov.jdbc=INFO<br>#<br><br>Sustituir INFO por DEBUG.<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><br></div><div>Y la segunda cuestión es que <b>entiendo que la conexión ( JDBCServerExplorerParameters ) no se añade al pool automáticamente al hacer un createStore si no que hay que añadir a mano</b> con algo tipo:<br></div><div><br></div><div><div>DataManager dataManager = DALLocator.getDataManager();</div><div>DataServerExplorerPool pool = dataManager.getDataServerExplorerPool();</div><div>pool.add(name, explorer);</div></div></div></blockquote><div><br><br>Estas mezclando dos conceptos. Conexiones a servidores con conexiones a fuentes o almacenes de datos. *ServerExplorer* hacen referencia a conexiones a servidores. No identifican una fuente o almacen de datos. Se utilizan para "examinar" un servidor. Preguntarle que capas ofrece y si puede crear o eliminar alguna. Se usa para "examinar" BBDD, sistemas de ficheros, servidor WFS,... Luego estan los "*Store*". Representan fuentes o almacenes de datos. Una tabla en una BBDD, un shape en un sistema de archivos, o una capa en un servidor WFS. DataServerExplorerPool hace referencia a un pool de parametros de "*ServerExplorer*" no de "*Store*". Para crear un DataStore se usa un DataStoreParameters y no un DataServerExplorerParameters, no podemos añadir al pool de DataServerExplorerParameters un DataStoreParameters.<br><br>Un DataServerExplorer tiene metodos como:<br><br>- list<br>- remove<br>- add<br><br>Para consultar las fuentes de datos que contiene ese servidor, eliminar alguna o añadir alguna.<br><br>Mientras que un DataStore (me centro en un FeatureStore) tiene cosas como:<br><br>- getFeatureSet() <br>- update(feature)<br>- insert(feature)<br>- delete(feature)<br><br>Que nos permiten obtener las features de ese almacen de datos, actualizarlas, añadir nuevas o eliminarlas.<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>Y lo último al utilizar DynObjects donde las claves están definidas en DBParameters da la impresión de que <b>puedo usar un JDBCServerExplorerParameters directamente como substituto de un JDBCStoreParameters</b> la hacer el dataManager.createStore(storeParameters);. Pero no lo he probado para ver si funciona y no se si es una buena práctica.</div><div><br></div></div></div></blockquote><div><br>Creo que con lo que he comentado al principio ya bastaria. Yo no lo haria.<br><br>Voy a comentar sobre otra cosa que no has preguntado, igual me adelanto o simplemente no lo harias, pero me he encontrado ya con dos desarrolladores que se han liado con ello y no les iba nada y no sabian por que, asi que te lo comento, por si te ahorro algun dolor de cabeza.<br><br>Cuando estamos accediendo a un shape, los desarrolladores de gvSIG 2 parece que tienen bastante asumido que para crear un store y realizar una consulta sobre el, lo normal es crear un FeatureStore, crear un FeaureQuery y obtener un FeatureSet llamando al FeatureStore.getFeatureSet pasandole el FeatureQuery. Sin embargo, cuando se han encontrado ante la necesidad de hacer lo mismo contra una BBDD postgres, en seguida han tendido a pasar del FeatureQuery e intentar hacer una consulta SQL en lugar de especificar el nombre de tabla en los parametros de conexion. La cosa funciona... mas o menos; pero en el mejor de los casos el rendimiento es muy muy muy deficiente. El mecanismo de creacion de FeatureQuerys es el mismo independiente de la fuente de datos, tanto sea un shape como una tabla de BBDD. Si no es imprescindible no atajes creando sentencias SQL que pasas en los parametros de conexion. El proveedor de acceso a BBDD se las maneja bastante bien cuando el crea las consultas, pero si tiene que mezclarlas con consultas tuyas ya no lo hace tan bien. Si precisas especificar una consulta SQL, normalmente para unir dos tablas por ejemplo, mi recomendacion es que crees una vista en la BBDD y luego, ya especifiques el filtrado si lo necesitas en gvSIG.<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><div><br></div><div>Gracias y disculpas por la chapa.</div><div><br></div></div></div></blockquote><div><br>No pasa nada por la "chapa", yo tiendo a meter algunas en mis correos ;)<br>Espero que te sirvan los comentarios.<br><br>Un saludo<br>Joaquin<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></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">El 18 de junio de 2016, 13:06, Joaquin Jose del Cerro Murciano <span dir="ltr"><<a href="mailto:jjdelcerro@gvsig.org" target="_blank">jjdelcerro@gvsig.org</a>></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"><div><div>El 17 de junio de 2016, 17:09, Francisco Puga <span dir="ltr"><<a href="mailto:fpuga@icarto.es" target="_blank">fpuga@icarto.es</a>></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">Hola,<br>
<br>
En la v1 las clases SingleDBConnectionManager o<br>
SingleVectorialDBConnectionManager permitían crear o registrar una<br>
conexión a una base de datos.<br>
<br>
¿Hay algún equivalente en la v2?<br>
<br>
Algún ejemplo de como crear y registrar una conexión a una bd postgres<br>
para luego cargar una capa por código sería genial :)<br></blockquote></div></div><div><br>Hola Francisco.<br><br>Me temo que no existe el equivalente en gvSIG 2.<br><br>Lo mas parecido podria ser el DataServerExplorerPool (que se puede obtener a traves del DataManager); pero no es exactamente lo que quieres, ya que es un pool de DataServerExplorer mientras lo que entiendo que quieres es un pool de DataStore.<br><br>Para la 2.3, tengo casi casi un pequeño script que le permitira al usuario mantener un "catalogo" de parametros de DataStore (el usuario simplemente lo ve como un catalogo de capas) que le permite añadir rapidamente una capa a la vista. Es posible que lo que precises sea eso, pero solo funcionara sobre la 2.3. Tiene un pequeño API a traves del ActionInfo que te permitira:<br>- añadir una capa del catalogo a la vista activa<br>- recuperar una capa del catalogo sin añadirla a la vista<br>- recuperar un DataStore del catalogo<br>- recuperar un DataStoreParameters del catalogo<br>- añadir una capa al catalogo<br>- añadir un DataStore al catalogo<br>- añadir un DataStoreParameters al catalogo<br><br>Pero me temo que no se podra empezar a probar hasta gvSIG 2.3 RC2.<br><br>Un saludo<br>Joaquin<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">
_______________________________________________<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><span><font color="#888888"><br>
</font></span></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>