[Gvsig_desarrolladores] Registrar una nueva conexión a bd

[Joaquin Jose del Cerro Murciano]

Hola,
primero un comentario y despues te voy comentando el resto entre lineas.
Una de las cosas que se ha intentado hacer en gvSIG 2, es separar mucho la
implementacion de los APIs.
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).
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.
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.

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).

Dicho esto te voy comentando entre lineas.

El 20 de junio de 2016, 13:38, Francisco Puga <fpuga en icarto.es> escribió:

> 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.
>
> Para ello hago algo de este estilo:
>
> public DataStoreParameters getParams() throws DataException {
>     DataManager dataManager = DALLocator.getDataManager();
>   DataStoreParameters pgParameters = null;
>   params =
> dataManager.createStoreParameters(PostgreSQLStoreProvider.NAME);
>     params.setDynValue("host", SERVER);
>     params.setDynValue("port", PORT);
>   params.setDynValue("dbuser", USERNAME);
>   params.setDynValue("password", PASSWORD);
> params.setDynValue("dbname", DBNAME);
> }
>
>

Yo eliminaria la referencia a PostgreSQLStoreProvider.NAME y la sustituiria
por una constante en tu proyecto.


> public FLyrVect createLayer(String schema, String table) throws
> DataException, LoadLayerException {
>   MapContextManager mapContextManager =
> MapContextLocator.getMapContextManager();
>   DataStoreParameters params = (DataStoreParameters)
> getParams().getCopy();
>   FLayer layer = mapContextManager.createLayer(table, params);
>   return (FLyrVect) layer;
> }
>


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.



>
> El MapContextManager.createLayer por debajo hace una llamada a:
>
> DataStore dataStore=dataManager.createStore(storeParameters);
>
> Entiendo que* 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 *si no que se reaprovecha la
> existente.
>


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:

#
# JDBC/PostgreSQL
log4j.logger.org.gvsig.fmap.dal.store.jdbc=INFO
log4j.logger.org.gvsig.fmap.dal.store.postgresql=INFO
log4j.logger.org.gvsig.exportto.swing.prov.jdbc=INFO
#

Sustituir INFO por DEBUG.




>
> Y la segunda cuestión es que *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* con algo tipo:
>
> DataManager dataManager = DALLocator.getDataManager();
> DataServerExplorerPool pool = dataManager.getDataServerExplorerPool();
> pool.add(name, explorer);
>


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.

Un DataServerExplorer tiene metodos como:

- list
- remove
- add

Para consultar las fuentes de datos que contiene ese servidor, eliminar
alguna o añadir alguna.

Mientras que un DataStore (me centro en un FeatureStore) tiene cosas como:

- getFeatureSet()
- update(feature)
- insert(feature)
- delete(feature)

Que nos permiten obtener las features de ese almacen de datos,
actualizarlas, añadir nuevas o eliminarlas.



>
> Y lo último al utilizar DynObjects donde las claves están definidas
> en DBParameters da la impresión de que *puedo usar un
> JDBCServerExplorerParameters directamente como substituto de un
> JDBCStoreParameters* la hacer el
> dataManager.createStore(storeParameters);. Pero no lo he probado para ver
> si funciona y no se si es una buena práctica.
>
>
Creo que con lo que he comentado al principio ya bastaria. Yo no lo haria.

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.

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.



>
> Gracias y disculpas por la chapa.
>
>
No pasa nada por la "chapa", yo tiendo a meter algunas en mis correos ;)
Espero que te sirvan los comentarios.

Un saludo
Joaquin


>
> El 18 de junio de 2016, 13:06, Joaquin Jose del Cerro Murciano <
> jjdelcerro en gvsig.org> escribió:
>
>>
>>
>> El 17 de junio de 2016, 17:09, Francisco Puga <fpuga en icarto.es> escribió:
>>
>>> Hola,
>>>
>>> En la v1 las clases SingleDBConnectionManager o
>>> SingleVectorialDBConnectionManager permitían crear o registrar una
>>> conexión a una base de datos.
>>>
>>> ¿Hay algún equivalente en la v2?
>>>
>>> Algún ejemplo de como crear y registrar una conexión a una bd postgres
>>> para luego cargar una capa por código sería genial :)
>>>
>>
>> Hola Francisco.
>>
>> Me temo que no existe el equivalente en gvSIG 2.
>>
>> 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.
>>
>> 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:
>> - añadir una capa del catalogo a la vista activa
>> - recuperar una capa del catalogo sin añadirla a la vista
>> - recuperar un DataStore del catalogo
>> - recuperar un DataStoreParameters del catalogo
>> - añadir una capa al catalogo
>> - añadir un DataStore al catalogo
>> - añadir un DataStoreParameters al catalogo
>>
>> Pero me temo que no se podra empezar a probar hasta gvSIG 2.3 RC2.
>>
>> Un saludo
>> Joaquin
>>
>>
>>
>>> _______________________________________________
>>> gvSIG_desarrolladores mailing list
>>> gvSIG_desarrolladores en listserv.gva.es
>>> Para ver histórico de mensajes, editar sus preferencias de usuario o
>>> darse de baja en esta lista, acuda a la siguiente dirección:
>>> https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>>>
>>
>>
>>
>> --
>> --------------------------------------
>> Joaquin Jose del Cerro Murciano
>> Development and software arquitecture manager at gvSIG Team
>> jjdelcerro en gvsig.com
>> jjdelcerro en gvsig.org
>> gvSIG Association
>> www.gvsig.com
>> www.gvsig.org
>>
>> _______________________________________________
>> gvSIG_desarrolladores mailing list
>> gvSIG_desarrolladores en listserv.gva.es
>> Para ver histórico de mensajes, editar sus preferencias de usuario o
>> darse de baja en esta lista, acuda a la siguiente dirección:
>> https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>>
>>
>
>
> --
> Francisco Puga
> iCarto | Innovación, Cooperación, Cartografía y Territorio S.L.
> http://www.icarto.es/
>
> c/ Rafael Alberti nº 13 – 1º D
> 15008 A Coruña
> Galicia (Spain)
> +34 881927808
>
> 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.
>
> 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).
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse
> de baja en esta lista, acuda a la siguiente dirección:
> https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>


-- 
--------------------------------------
Joaquin Jose del Cerro Murciano
Development and software arquitecture manager at gvSIG Team
jjdelcerro en gvsig.com
jjdelcerro en gvsig.org
gvSIG Association
www.gvsig.com
www.gvsig.org
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20160620/ccab38f3/attachment.htm