A veces es necesario hacer cambios a nuestra base de datos, y siempre estaremos lidiando con las herramientas gráficas o desde la consola, con los cambios en la base de datos, pero existen formas de hacer este trabajo “sucio” mucho más rapido y ahorrando tiempo.

En nuestro caso, usaremos Spring 2.5 y Hibernate 3.3 y MySQL, donde es necesario ya tengas armado los beans de conexión a la base de datos. El siguiente código es un array de cadenas, si en nuestro caso tenemos segmentado los xml de spring, los añadiremos de la siguiente manera.

// array de string para agregar todos tus archivos de configuración de spring
private static final String[] SPRING_CONFIG_FILES =
new String[]{"source/spring/config/xxxxxx-db-context.xml", "source/spring/config/xxxxxxx-param-context.xml"};

A continuación, el código necesario para generar nuestra base de datos, el FileSystemXmlApplicationContext carga el Contexto de la Aplicación, y una vez teniendo el contexto obtenemos el SessionFactory, que en nuestro caso usamos Anotaciones, creamos el bean en base a la clase AnnotationSessionFactoryBean , esto es importante pues en base a esta clase usaremos los metodos dropDatabaseSchema(); para borrar el actual schema (tablas, relaciones , etc) y luego ejecutamos createDatabaseSchema(); para crear el nuevo schema.

// carga el application context de Spring
 FileSystemXmlApplicationContext appContext = new FileSystemXmlApplicationContext(SPRING_CONFIG_FILES);
// Obtiene el bean del session factory
 AnnotationSessionFactoryBean annotationSF = (AnnotationSessionFactoryBean)  appContext.getBean("&sessionFactory");
// si quieres eliminar el schema de la base de datos
 annotationSF.dropDatabaseSchema();
// para crear nuevamente el schema de la base de datos
 annotationSF.createDatabaseSchema();

Los archivos de configuración de Spring, deben lucir de la siguiente manera, hay que destacar el hibernate.dialect donde indicamos el dialecto que usaremos para crear el schema, en el caso de MySQL puede ser MySAM o InnoDB, luego el parametro hibernate.hbm2ddl.delimiter que también indicamos el tipo de tablas que usaremos en mi caso usaré type=InnoDB.

<bean id="dataSource"
        class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName" value="${datasource.classname}" />
        <property name="url" value="${datasource.urldb}" />
        <property name="username" value="${datasource.userbd}" />
        <property name="password" value="${datasource.pass}" />
    </bean>
 
    <bean id="sessionFactory"
        class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="annotatedClasses">
          <list>
              <value>Clase1</value>
              <value>Clase2</value>
          </list>
        </property>
        <property name="hibernateProperties">
           <props>
                <!-- <prop key="hibernate.hbm2ddl.auto">update</prop> -->
                <prop key="hibernate.dialect">${datasource.dialect}
                </prop>
                <prop key="hibernate.show_sql">${datasource.showsql}</prop>
                <prop key="hibernate.hbm2ddl.delimiter">${datasource.delimited}</prop>
            </props>
        </property>
      </bean>

MySQL ha presentado un nuevo modelo de lanzamientos, la finalizad de los cambios es crear un modelo más dinámico, accesible, abierto y fácil de entender, todo esto con apresurar la salida de MySQL 6.0, el nombre clave del siguiente lanzamiento será Azalea (como puedes apreciar en el gráfico). El nuevo modelo se explica de la siguiente manera:

• La rama trunk está siempre por lo menos en calidad Beta.
• Un hito (milestone) comienza siempre en calidad Beta (nunca en Alpha) con una fusión (merge) entre las ramas trunk y stage.
• Los lanzamientos de los hitos (milestones), con calidad de RC (Release Candidates), serán cada 3 o 6 meses.
• Las ventanas de integración entre los hitos permitirán la inserción de nuevas características de las ramas de stages.
• Los lanzamientos GA (General Availability) sucederán cada 12 a 18 meses.
• Nunca habrá más de dos lanzamientos con soporte activo.