Manejar 2 Bases de Datos con Spring ROO

Hola,

Hice una persistencia con Spring ROO para una bd mysql, pero ahora necesito hacer otra, el problema es que si sigo los mismo pasos para crear la segunda persistencia, la crea, pero sobreescribiendo la primera.

¿Cómo podría hacer para tener las dos persistencias? , ¿Creando la segunda manualmente? ¿o hay alguna manera de hacerlo con Spring ROO, sin sobreescribir la primera?

Saludos

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

interesante

A ver si los que manejan Roo te pueden contestar; este punto es interesante porque es donde se muestra qué tan flexibles son este tipo de productos, que muchas veces sacrifican flexibilidad por rapidez; puedes hacer una aplicación típica muy rápido, pero en cuanto tu aplicación se sale de su definición de "típico" estás en problemas.

Re: Interesante

¿Porqué siempre la comparación?...Que si flexible, que si estable, que si rápido.

Bien, recuerden una herramienta (en esta caso framework) viene o trae cosas preconfiguradas para ciertas tareas para las cuales el framework es la solución. Sin embargo existe la posibilidad de cambiar dichas configuraciones (o evitarlas). Es cómo el mito ese de que Rails no se acopla a sistemas con BDs legacy y muchos otros frameworks (pero es Rails y las soluciones parecidas a éste son las más criticadas) .

Respecto al post existe un dicho muy bueno llamado: "Back to the basics" o "de vuelta a lo simple". A mi se me ocurren 3 soluciones:

  1. Intenta una conexión JDBC.- Para esto no necesitas configurar lo que ya tienes en ejecución.
  2. Configura una segunda conexión por medio de un ORM.- Con Hibernate puedes asignarle a qué fichero de configuración apuntar (verificar cómo hacerlo en el Tutorial de Hibernate para la comunidad, que de momento no lo recuerdo).
  3. Utiliza un web-service.- En donde por medio de parámetros envíes y recibas información.

Hay una frase que recuerdo haber leído en un blog:

Hay ocasiones en dónde uno no puede salir sin mancharse las manos. Sin embargo no por ello quiere decir que algo sea malo. Todo depende en lo importante: Resolver los problemas que se nos presentan y qué tan cómodo te sientas usando X o Y herramienta.

Y para el del post, recuerda que Spring Roo o cualquier framework no van a ser la solución completa a la totalidad de tus problemas, quizás resuelva pocos, muchos o la mayoría, pero es raro (a no ser que hagas siempre el mismo tipo de proyectos) que resuelva TODOS Y CADA UNO de tus problemas.

Saludos =).

Imagen de ezamudio

comparación?

No comparé con nada... simplemente menciono que una de las limitantes de los frameworks para RAD siempre ha sido que sirven muy muy bien para casos generales pero en cuanto te sales tantito del caminito por el que te llevan luego resulta que no puedes hacer nada al respecto; hoy en día los frameworks tipo Roo ya deberían permitirte "colorear fuera de la raya", es decir, permitirte hacer cosas como el caso de las dos datasources, sin tener que sufrir mucho. Muy probablemente se puede hacer, la pregunta original es ¿cómo se hace?

Las opciones 1 y 3 me parecen subóptimas. La primera seguramente será una prueba exitosa pero no prueba nada. Y la 3... hacer un web service para conectarse a una base de datos, cuando se tiene directamente acceso a la base de datos, es tal y como ya dije, subóptimo (subsubsubsusubsubóptimo). Y la segunda pues tal vez lo saque del apuro por ahora, pero si luego quiere usar Hibernate con el datasource que ya tenía desde el principio?

Imagen de javiher

Gracias!

Hola,

Gracias por las respuestas,

Lo único que he encontrado ha sido esto --> , pero según los comentarios de otros usuarios han tenido problemas a la hora de ingresar datos en la base de datos.

También he visto que lo han reportado al sistema de bugs y parece que hay una respuesta, lo voy a mirar -->

De momento sigo como lo estoy haciendo en javaSe con 2 archivos de configuración hibernate y dos de ingeniería inversa (uno para mysql y otro para ora), los archivos de mapeo también los tengo ya para ambas bases de datos, lo que me queda es editar la clase de Utilidad para manejar 2 session factorys, que es donde más me lío.

No se peleen :) , no vale la pena. jeje vengo de una discusión y me encuentro con otra. Aunque ganas no me faltaron de estamparle la cabeza contra algo, al amachado que me encontré hoy empujando a su pareja y llamándola guarra, si le llega a poner la mano encima, le estampo la cabeza contra algo.

Lo peor fue un comentario de un individuo que estaba allí que va y dice "que las maten a todas", tiene narices el tipo también. (lo decía porque los mujeres no lo denuncian, por miedo normalmente).

Y para el del post, recuerda que Spring Roo o cualquier framework no van a ser la solución completa a la totalidad de tus problemas, quizás resuelva pocos

Gracias por recordármelo, Estoy experimentando con ROO nada más.

El del post, se llama Javier, el nick javiher es porque está junto el nombre con el apellido. (javi her-nandez , y como la h no se pronuncia queda javier ;)

Saludos

Re: comparación?

Desconozco el método o las posibilidades para conectar a bases de datos.

Por óptimas supongo puedes referirte a eficaces y eficientes, en donde creo que la opción 1 es la más óptima (porqué es mucho más rápido que cualquier ORM).

¿La segunda algo que saca de apuro y sólo parcialmente?. Creo que hibernate te da esa posibilidad y los proyectos "hechos a pie" así es cómo funcionan, en donde tienen más de 1 fuente de datos configurada a través de varios ficheros de configuración. ¿Y si quiere acceder a Hibernate con su fuente de datos original?...Pues bien puede crear un fichero de configuración hibernate para dicho datasource. Digo, la posibilidad ahí está.

La 3 la puse, ¿porqué?, pues porqué quizás tiene alguna restricción para acceder a la DB cómo se debe. En fin ¿puede funcionar?, yo creo que si.

Una cosa que me llamó la atención fue:

La primera seguramente será una prueba exitosa pero no prueba nada.

Y es que no hay nada que probar más que con Spring Roo (o con cualquier otro framework) se puede acceder a diferentes fuentes de datos con varios métodos, lo que en otras palabras es: "El framework no te ata de manos."

Saludos.

Re: Gracias!

No créeme he visto peleas de @ezamudio y esto está lejos de ser una pelea, son sólo notas aclaratorias.
Seguido, pues lo que haces con hibernate desde mi punto de vista está bien (2 ficheros de configuración para conectar)...pero los de mapeo ¿para qué?. Te recomendaría mejor utilizar las anotaciones, son más "automáticas" que el xml y (en mi poca experiencia) dan menos lata. Ya con eso bastaría para conectarte a múltiples fuentes de datos y no tendrías ningún problema (no tendrías 2 archivos xml por clase -algo que a mí me fastidia-).

Jejejeje, saludos y pues así es muchas veces cómo me las he arreglado con Play! o Roo.

Imagen de ezamudio

peleas...

No son peleas, es una discusión cordial y creo que es lo que me hace regresar al sitio porque se aprende mucho con este tipo de discusiones.

De acuerdísimo con que es mejor usar anotaciones JPA (y una que otra adicional de hibernate, o mejor las de JSR-303) que estar peleándose hoy día con el mapeo via XML. Lo que yo digo de que no es una solución óptima, es por la manera en que se propone. Estamos suponiendo que actualmente no se usa hibernate en la aplicación, y solamente hay un datasource. Entonces para tener un segundo datasource hay que usar hibernate, de modo que se puede usar el primer datasource de manera directa y el segundo por medio de hibernate. Pero veo dos problemas con esto: primero, que para hibernate hay que definir un datasource, y ese es precisamente el problema que se postuló originalmente: no se puede crear (aparentemente) un segundo datasource en una aplicación Roo. Entonces no sé cómo harían para crear el segundo datasource de manera que sólo Hibernate lo vea. Y aun si lo logran; qué pasa si quieren usar Hibernate también con el primer datasource? es posible tener dos sessionFactories o tampoco lo permite el framework?

Quiero que conste que no sé de lo que hablo porque no he usado Roo pero he visto demos y leído acerca del objetivo del framework, me parece bueno pero ya he visto antes otros frameworks de RAD no sólo para Java sino algunos que hasta son su propia plataforma y/o traen su propio lenguaje, y la bronca es que te permiten hacer muchas cosas pero en cuanto quieres hacer algo que los creadores del framework no concibieron, se vuelve un problemón.

Re: peleas...

Pues es que yo cuando aprendí hibernate se podía configurar la conexión por medio del hibernate.cfg.xml o algo así. Eso es lo que propongo. De utilizar hibernate de inicio no importaría, puedes tener un original.cfg.xml y un segundo.cfg.xml y un tercer.cfg.xml; hibernate te lo permite para esos casos (en donde tienes que utilizar más de una fuente de datos). Y luego haces algo así:
 

Y ya el mapeo, pues creo que a fuerzas con configuración xml. Pero pues ya resuelves eso y aquí puede existir una manera de hacerlo sin irse a la 'old-school'.

EDIT: Encontré esto que me parece muy interesante para hacerlo todo con JPA y con el fichero persistence.xml, se ve algo tedioso pero pues parece funcionar. Y también encontré algo más bonito (dependiendo sólo en JPA y su único fichero de config).

Imagen de javiher

Gracias de nuevo!

Hola,

Sí eso es, yo he configurado cada una con un archivo cfg.xml y otro reveng.xml (ej. OraHibernate.cfg.xml) Luego hice los mappings files y los POJOS, ya hice la clase de utilidad para hibernate, a ver si la ven bien, porque no la he probado aún, y no estoy seguro..

 
Luego la idea es realizar las consultas con el lenguaje de hibernate HQL o quizás, según se me de, con Criteria.

 

No sé si lo verán bien así.

Referente a ROO (por cierto gracias porque no conocía Play), me parece muy interesante poder hacer todo desde la consola sin tener que levantar el ide.

Saludos

Re: Gracias de nuevo!

Desde mi punto de vista está bien. Aunque para mí es incómodo configurar los mapeos en XML (por ello puse las ligas en el EDIT del comentario), pero no por ello creo que sea peor.

Algo que me llama la atención es:

Referente a ROO (por cierto gracias porque no conocía Play), me parece muy interesante poder hacer todo desde la consola sin tener que levantar el ide.

A lo qué digo: +1