Usando dos bases de datos diferentes con archivos de mapeo de hibernación idénticos

Question

Básicamente, la idea es utilizar los mismos archivos de mapeo de hibernación para dos bases de datos subyacentes diferentes.En producción, la base de datos subyacente es MySQL5 y, para fines de prueba, me gustaría usar Apache Derby, para evitar configurar y mantener varias bases de datos MySQL con fines de prueba.

Esperaba que simplemente cambiar el controlador de DataSource y cambiar algunos parámetros funcionara, pero ya me he encontrado con algunas dificultades menores.De hecho, hay dos preguntas.La primera pregunta concreta es:

I.¿Es posible decirle a Derby qué tipo de datos usar si un tipo de datos está disponible en MySQL y no en Derby?El mapeo es el siguiente:

  <property name="about">
    <column name="`about`" not-null="false" sql-type="text"></column>
  </property>

Derby no conoce el "texto" de tipo SQL, por lo que se niega a crear la tabla.Se trata de Derby 10.4.2.0 e Hibernate 3.2.6.por cierto.

II.¿Cuál es su experiencia con el uso de dos bases de datos diferentes para pruebas y producción?Sé que hay algunos inconvenientes que, p.no puede probar procedimientos almacenados o consultas específicas de bases de datos, pero, por otro lado, hace que las pruebas sean más fáciles y rápidas (si finalmente lo ejecutó).¿Qué opinas?

Answer 1

Pregunta n.º 1: no especifique el tipo de SQL;usar Tipo de hibernación en cambio:

<property name="about" type="string" length="4096"/>

Luego puede extender el dialecto Derby (o MySQL) proporcionado por Hibernate para asignar ese tipo al tipo de base de datos apropiado según la longitud (no) especificada.Eche un vistazo a MySQLDialect para ver un ejemplo;asigna el tipo de cadena a cualquiera varchar o uno de text tipos basados ​​en la longitud.

Pregunta #2: ¿te refieres a usar diferentes bases de datos para desarrollo y producción?Porque usar diferentes bases de datos para pruebas y la producción es como jugar a la ruleta rusa con el cañón completamente cargado: no vas a ganar :-)

Siempre debe probar todas las configuraciones de implementación aplicables.Usar diferentes bases de datos para desarrollo y producción no es un mal enfoque si realmente necesita admitir ambos, ya que ayuda a localizar los problemas de portabilidad con anticipación.

Answer 2

La razón principal para usar un tipo diferente de base de datos en la prueba es, en mi opinión, para tener pruebas unitarias más rápidas donde no es práctico falsificación o burlarse de la base de datos (aunque cuando puede usted debe hacer esto último). Tenga en cuenta que debe haber una sesión de puesta en escena, donde las pruebas se pueden ejecutar en contra de un tipo de producción de base de datos para asegurarse de que no está codificando a la base de datos de prueba. También le obliga a codificar a una base de datos genérica -. A veces es una buena idea y, a veces eso no es

Es evidente que si se necesita una función específica de base de datos (procedimiento almacenado o incluso tipo especial) se debe utilizar el mismo tipo.

En el caso de MySQL, puede configurar las tablas de una prueba para que sea almacena en la memoria . Si es probable que necesite artículos específicos que MySQL es una opción. Si el objetivo es ser la base de datos genéricos que el uso de una base de datos diferente en las pruebas de desarrollo / nivel bajo puede ser una buena cosa.

Answer 3

No debe haber ningún problema para utilizar diferentes proveedores de bases de datos en diferentes entornos (prestar atención a que la respuesta de ChssPly76 pruebas y de producción deben ser los mismos). Aunque no he probado Derby (todavía).

En lo personal me gusta usar HSQLDB para el entorno de desarrollo. Es pequeño, flexible y fácil de transportar, lo que requiere poca o ninguna configuración. El uso de una herramienta como Unitils para pegar juntos Hibernate, DbUnit y JUnit ha funcionado muy bien para mí. Antes se ejecutan las pruebas JUnit la HSQLDB se carga con datos de prueba estáticas. Esto permite que la capa de pruebas JUnit tienen acceso a datos para las afirmaciones basadas en datos reales (que se carga de algunos archivos xml que se sientan cerca de las pruebas).

(Una palabra de advertencia con Unitils es que el valor por defecto "loadStrategy" es dejar caer todos los datos existentes antes de la carga, por lo que tener cuidado donde se señala que la cosa).

Answer 4

En mi experiencia, los más implementaciones de bases de datos que prueban con, cuanto antes se encuentras los lugares donde se han dependido accidentalmente en algo que es a través de bases de datos no portátiles.

Si Derby está haciendo su prueba más rápida y más fácil, entonces eso es un gran resultado, ya que más rápido y más fácil la prueba anima a más pruebas.

Creo que Derby es una excelente opción para las pruebas con, como Derby se esforzaba mucho para cumplir el estándar SQL y para admitir sólo la sintaxis y los comportamientos que se especifican en la norma, por lo que este debería ayudar a asegurar que usted está evitando uso de las características de base de datos no estándar.

Pero estoy de acuerdo que a medida que se acerca al implementar la aplicación, es necesario estar poniendo a prueba utilizando una configuración que es lo más cerca posible a la configuración de despliegue previsto.