2010-10-05 10 views
7

Ésta es mi bean sin estado:¿Cómo se definen dos unidades de persistencia (una para producción, una para prueba unitaria)?

@Stateless 
public class Finder { 
    @PersistenceContext(unitName = "production") 
    EntityManager em; 
    [...] 
} 

Se define explícitamente que el nombre de la unidad de persistencia es production. Esta unidad está configurada en persistence.xml, y todo está bien. Cuando estoy probando la unidad de esta clase, tengo que usar otra unidad de persistencia, con diferentes conjuntos de propiedades y configuración. ¿Cómo debería organizarlo? Crear otro elemento <persistence-unit> en persistence.xml? ¿Existe alguna mejor práctica para esto?

Respuesta

8

Uso el mismo nombre de unidad persistente pero diferentes archivos persistence.xml (¿cómo va a automatizar las pruebas si necesita editar el código para habilitar el "modo de prueba"?).

Si usted todavía está utilizando Maven, Maven es compatible de forma nativa con las versiones de prueba de los archivos de configuración:

  • la "producción" persistence.xml pasa por debajo de src/main/resources/META-INF
  • la "prueba" persistence.xml pasa por debajo de src/test/resources/META-INF y se usa para las pruebas.
+1

Gracias, esto es lo que estaba buscando (copia de prueba de 'persistence.xml'). Por supuesto que estoy usando Maven, ¿qué más? :) – yegor256

+0

@Vincenzo Exactamente, ¿qué más? :) –

+0

@PascalThivent Pascal Considero altamente todas sus respuestas SO. ¿Me puede decir por qué usa un persistence.xml separado con una PU que tiene el mismo nombre? Me doy cuenta de que es conveniente de esta manera si Maven puede elegir la PU correcta para usar. Sin embargo, mis proyectos no están mavenizados, así que tengo que pasar por algunos aros más para usar dos archivos persistence.xml. Dado que dos archivos persistence.xml llevan a la duplicación de la configuración, ¿qué otros beneficios provienen del uso de dos archivos persistence.xml diferentes? –

2

Simplemente creé otro elemento <persistence-unit> en persistence.xml.

+0

¿Y cómo le indica al contenedor que use otra unidad de persistencia? – yegor256

+0

@Vincenzo - Utilizo Spring para configurar eso, tengo un applicationContext.xml y un testApplicationContext :) – willcodejavaforfood

0

Se puede crear una segunda unidad de persistencia en la configuración, pero eso no necesariamente significa que debe . Múltiples unidades de disco son, por supuesto, completamente correctas y adecuadas, pero me mantendría alejado de mezclarlas cuando sean específicamente para diferentes entornos, p. producción versus prueba.

En su instancia, tendría dos archivos de configuración de persistencia, y la herramienta Ant/Maven/build de su elección puede copiar/renombrar la correcta cuando corresponda.

0

Tuve un problema similar y deseo proporcionar otro enfoque. Quise ejecutar test y prod, pero no uso dos persistence.xml o modificaciones de código. Solo tengo una unidad de persistencia, pero diferentes entornos de ejecución (standalone.xml, Wildfly). Digamos que quiero correr contra mi base de datos de desarrollo, inicio Wildfly con el entorno de ejecución de prueba. Cuando quiero simularlo como usuario real, corro contra el entorno de producción. La única diferencia es la entrada del origen de datos en standalone.xml. El descriptor es siempre el mismo (por ejemplo, myappDS, por lo que la declaración de unidad de persistencia en persistence.xml siempre es la misma), pero en el servidor de prueba la fuente de datos de datos apunta a mi base de datos de prueba, en prod los puntos de entrada de la fuente de datos a mi base de datos prod.

Cuestiones relacionadas