A Sip of Java: Encapsulate collection attributes

Encapsulation is the ability we give our classes (and objects created from them) to hide the implementation details of their inner workings and control the consistency of the internal state and invariants.

It happens all the time that we expose some attribute in our class to the outside world in the form of a collection like the following:

This is actually pretty common and I think a bad practice, we tend to create private fields in our classes and as a reflex create setters and getters immediately without thinking about the consequences of exposing the state that way.

If we simply return the reference to the attribute of the object there is a lot of danger there because now others have a copy of the reference to that attribute that is supposed to be private and under the control of the owner object.

Imagine if some code that gets that list of emails from our class now tries to modify the content of that list by adding or removing some objects from it. How can we control that? what if there is some kind of limit on the number of emails a Contact can have? How can we ensure only valid emails are added?

What if, instead, we write the following:

Now users of our class will get a list of emails that cannot be modified. New Email objects cannot be added or removed (but still the objects in the list can be changed if the public methods in the Email class allow that 😉). You could also create a copy of the list of emails by instantiating a new ArrayList sending the list of emails as an argument to the constructor new ArrayList<>(this.emails) but I still think it is better to fail when trying to modify the list.

Probably it is even better to just expose public methods with just the exact functionality that we want to allow like the following:

With the last implementation, we are hiding more and then have even more control. For example, let's say a Contact can have thousands of Emails (I know, it is unlikely, but let's say that is possible), then we can even change internally the way we store Emails from a List to a Map and then be able to have better performance for some operations, like removing an Email.

Do you have suggestions on how to improve the information hiding here? please comment!

A Sip of Java: Stream.flatMap()

 Let's say you have a map where you store a list of values for each key, something like:

And now you want a single list with all values in the Map. Then you need to use flatMap:

Map.values() returns a collection of the values for each key in the map, since each value is a list of Strings, it will return a collection of list of strings.

But you want a single list with all strings right?

Ok, then use Stream.flatMap() method to get a stream for each list in the collection of values and then merge all lists into a single list.

Simply put, convert a Stream of Stream of values into a single list of values.

Elixir Development with Visual Studio Code

Hi! the actual post is here: https://medium.com/@abadon.gutierrez/elixir-development-with-visual-studio-code-16b923e82653

Ecto 101: Intro, configuración y manipulación de datos sin esquemas

Estoy empezando otro blog en Medium, y escribi sobre como empezar con Ecto.

Ecto 101: Intro, configuración y manipulación de datos sin esquemas

Desde el 2012 no he escrito nada en este blog. Deberia retomarlo.

Linux: Administración de espacio en disco

Entrada original en: http://itbrainblog.wordpress.com/2012/10/02/linux-administracion-de-espacio-en-disco/

Todos nos hemos topado con el problema de espacio en disco, ya sea porque en nuestra maquina se nos acaba el espacio por tanto mp3's o videos o en el servidor que estamos administrando los backups y logs que se generan empiezan a consumir ese precioso espacio que al final nos puede afectar en el rendimiento del sistema operativo y por consiguiente de las aplicaciones que ahí corren. Es necesario conocer los comandos adecuados para conocer el espacio que se esta ocupando, quien lo esta ocupando y ver que podemos eliminar para poder tener mas.

Conocer el espacio usado en disco

Lo que primero hay que conocer es el total de espacio que estamos usando en el disco duro y para realizar eso usamos el comando:

df -h

El cual nos dice el espacio del Sistema de archivos en la columna Size, el espacio usado en la columna Used, el espacio disponible en la columna Avail y el porcentaje que representa el espacio usado  y por ultimo el punto de montaje de ese sistema de archivos. Se usa la opción "h" (human-readable) para que nos de valores que nos arroje el comando vengan en valores de Kilobytes, Megabytes o Gigabytes y no en bloques que es como por default imprime los valores.
Conocer el espacio usado por un folder en especifico
Ahora, si lo que deseamos conocer es el espacio especifico de un folder debemos correr el comando:

du folder -ha

Donde folder es el nombre o ruta hacia el folder del cual queremos conocer el espacio que esta usando. Como salida este comando imprime el tamaño de cada uno de los archivos y folders contenidos dentro de el. Se usa la opción "h" para, igual que en el comando 'df', los valores que arroje vengan en Kilobytes, Megabytes o Gigabytes. La opción "a" (all) se usa para que se impriman el tamaño tanto folders como archivos ya que si no se usa esta opción solo se imprimen folders. Existen otras opciones a usar para este comando y como en la mayoría de los comandos en linux esas opciones se puede conocer ejecutando el comando de la siguiente forma:

du --help

La salida del comando 'du' se podría ordenar para así poder obtener, por ejemplo, los 10 folders y archivos que son los que ocupan mas espacio dentro de un cierto folder:

du folder -ka | sort -n -r | head -n10

Se usa la opcion 'k' en el comando 'du' para que en lugar de que nos imprima valores en Kilobytes, Megabytes o Gigabytes solo imprima todos los valores unificados a Kilobytes y el comando 'sort' pueda ordenarlos de manera uniforme. Y para solo obtener los 10 primeros se utiliza el comando 'head'. Así que si, por ejemplo, se desea obtener los primeros 5 solo hay que variar el valor en la opción 'n' del comando 'head'. Pero si lo que se desea saber es el tamaño total de cierto folder sin tener que ver el tamaño de su contenido se usa el comando:

du folder -hs

La opción 's' (summarize) hace que solo se imprima el valor total del folder si que se muestre el tamaño de cada folder y archivo que contiene. Hay que tomar en cuenta que para obtener los valores de tamaño el comando tiene que recorrer el contenido del folder para ir sumando el tamaño de cada elemento que contiene, así que, si el folder es muy grande la ejecución de este comando puede tardar.

Borrar archivos y folders

Ya que se conoce el elemento que se desea borrar se hace uso del comando 'rm' para eliminarlo. Si se trata de un archivo se usa el comando:

rm archivo

pero si se trata de un folder y nos interesa borrar el mismo y su contenido, se usa el comando:

rm -rf folder

hay que tomar en cuenta que una ves borrados ya no es posible recuperarlos así que estos comandos se tienen que usar con mucho cuidado.

Archivo basico log4j.properties

El archivo simple de lo4j.properties con el que inicio en los proyectos y como siempre se me esta olvidando, mejor lo posteo:

Noten que esta el appender de Spring Framework, si no lo usan pues quitenlo.

Configurar Alfresco para usar MySQL

Configurar Alfresco para usar MySQL

La instalación de Alfresco Community Edition 4.0d por default configura PostgreSQL como su base de datos pero si usas MySQL, como es nuestro caso, tal vez quieras no usar tantas bases de datos y unificar a que todas las Apps de tu Sistema usen MySQL.

Configuración para usar MySQL

Crear una base de datos 'alfresco' al igual que un usuario 'alfresco' con privilegios suficientes para realizar cambios al esquema 'alfresco' (esto es debido a que al iniciar Alfresco crea las tablas/datos necesarios, después se podrían quitar los privilegios para alterar la base de datos).

CREATE USER alfresco IDENTIFIED BY 'alfresco';

CREATE SCHEMA alfresco;

GRANT ALL TO alfresco@localhost IDENTIFIED BY 'alfresco';

Editar el archivo [instalacion_alfresco]/tomcat/shared/classes/alfresco-global.properties:

db.name=alfresco
db.username=alfresco
db.password=alfresco
db.host=localhost
db.port=3306
db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://${db.port}/${db.name}
db.pool.validate.query=select 1

Colocar el jar del driver MySQL en el folder lib de Tomcat, que esta ubicado en [intalacion_alfresco]/tomcat/lib.

NOTA: Se puede usar otro usuario, password, y nombre de esquema distinto al especificado aquí, no hay restricción. Solo hay que colocar correctamente los nombres que se lleguen a usar en el archivo alfresco-global.properties.

Reconstruir los indices de Solr

Posiblemente hay que obligar a Solr a que reindexe, para lograr eso hay que realizar lo siguiente:

1. borrar el folder en [instalacion_alfresco]/alf_data/solr/archive/SpacesStore/index
2. borrar el folder en [instalacion_alfresco]/alf_data/solr/workspace/SpacesStore/index
3. borrar los archivos en [instalacion_alfresco]/alf_data/solr/archive-SpaceStore/alfrescoModels/*
4. borrar los archivos en [instalacion_alfresco]/alf_data/solr/workspace-Spacestore/alfrescoModels/*
5. Reiniciar Alfresco

Clean Coders

Hace unos días Robert C. Martin (mejor conocido como Uncle Bob) libero un sitio con vídeos para profesionales de Software llamado cleancoders.com.

Hasta el momento solo tiene 2 vídeos, uno de ellos es introductorio a lo que vamos a poder encontrar en el sitio y el segundo habla de las buenas practicas al usar "nombres" en nuestro código. Los vídeos no son gratis, hay que comprarlos y el único método por ahora para poder adquirirlos es teniendo una cuenta en paypal.

Si ya han visto el estilo de Uncle Bob para dar presentaciones sabrán que es muy agradable y divertido para exponer los temas. En el caso de los vídeos que encontramos en cleancoders.com, va mucho mas allá ya que se apoya de mas recursos multimedia y efectos para llamar nuestra atención. Debo confesar que en varias ocasiones viendo estos vídeos si solté varias carcajadas.

Una cosa que no me gusto (o no he visto bien) es que los vídeos solo se puede ver en linea, no puedes bajarlos, ni meterlos a tu celular, ipod, o lo que sea. Claro que se entiende porque no dejan bajarlos ya que fácilmente podríamos "compartirlos" con alguien mas.

El vídeo introductorio solo tiene el costo de $1 dolar, el segundo ya cuesta $12 dolares. Al principio no se me hizo caro, pero me puse a pensar que si llegase a sacar 10 vídeos ya serian $120 dolares y eso ya es una lana.

En fin, los vídeos esta muy recomendables, si son caros o baratos pues ya dependerá de cada quien, pero de que se aprende algo se aprende.

De hecho, a partir de ver estos vídeos regrese a ver mi lista de wishlist en Amazon y por fin me anime a pedir mi copia de libro Clean Code del propio Robert C. Martin.

Ingeniería reversa de base de datos con Spring Roo

Desde hace ya tiempo quería probar esta nueva funcionalidad de Spring Roo.

La versión de Roo que estoy usando es: 1.1.0.RC1.

Hace ya algunas versiones anteriores de Spring Roo, los desarrolladores de esta herramienta habían prometido implementar algún mecanismo para poder hacer ingeniería reversa de un esquema de base de datos existente y generar código Java a partir de el. Pues ya han cumplido y han agregado los siguientes comandos a la consola de Roo:

• database reverse engineer. Este comando es el que realiza la 'magia' de crear/sincronizar las entidades a partir de una base de datos existente.


• database introspect. Este comando muestra los metadatos almacenados por Spring Roo de la base de datos.

Se recomienda que cuando estas haciendo un proyecto en el cual se esta usando un framework ORM como Hibernate o JPA el diseño del esquema de la base sea un derivado del diseño de las clases que contendrá el proyecto. Pero no siempre es así, ya sea porque en el equipo se tiene a una o varias personas especializadas en diseño de base de datos o porque se trata de un proyecto para el cual ya se tiene una base de datos existente.

Para empezar crearemos un proyecto con el clásico comando 'project':

roo> project --topLevelPackage com.jabaddon.roo.dbtopojo

La ejecución de este comando genera lo siguiente:

Created /Volumes/AbaddonData/Abaddon/Projects/JAbaddon/SpringRooProjects/BDToPojos/pom.xml
Created SRC_MAIN_JAVA
Created SRC_MAIN_RESOURCES
Created SRC_TEST_JAVA
Created SRC_TEST_RESOURCES
Created SRC_MAIN_WEBAPP
Created SRC_MAIN_RESOURCES/META-INF/spring
Created SRC_MAIN_RESOURCES/META-INF/spring/applicationContext.xml
Created SRC_MAIN_RESOURCES/log4j.properties

Lo siguiente es configurar la persistencia del proyecto:

roo> persistence setup --provider HIBERNATE --database MYSQL --databaseName roo_db_pojo --userName xxxx --password yyyy

Donde 'xxxx' se refiere al nombre del usuario y 'yyyy' al password del mismo para conectarse a la base de datos con nombre 'roo_db_pojo'.

La ejecucion del comando para configurar la persistencia genera lo siguiente:

anaged SRC_MAIN_RESOURCES/META-INF/spring/applicationContext.xml
Created SRC_MAIN_RESOURCES/META-INF/persistence.xml
Please enter your database details in src/main/resources/META-INF/spring/database.properties.
Created SRC_MAIN_RESOURCES/META-INF/spring/database.properties
Managed ROOT/pom.xml [Added dependency mysql:mysql-connector-java:5.1.13]
Managed ROOT/pom.xml [Added dependency org.hibernate:hibernate-core:3.5.5-Final]
Managed ROOT/pom.xml [Added dependency org.hibernate:hibernate-entitymanager:3.5.5-Final]
Managed ROOT/pom.xml [Added dependency org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.0.Final]
Managed ROOT/pom.xml [Added dependency org.hibernate:hibernate-validator:4.1.0.Final]
Managed ROOT/pom.xml [Added dependency javax.validation:validation-api:1.0.0.GA]
Managed ROOT/pom.xml [Added dependency cglib:cglib-nodep:2.2]
Managed ROOT/pom.xml [Added dependency javax.transaction:jta:1.1]
Managed ROOT/pom.xml [Added dependency org.springframework:spring-jdbc:${spring.version}]
Managed ROOT/pom.xml [Added dependency org.springframework:spring-orm:${spring.version}]
Managed ROOT/pom.xml [Added dependency commons-pool:commons-pool:1.5.4]
Managed ROOT/pom.xml [Added dependency commons-dbcp:commons-dbcp:1.3]
Managed ROOT/pom.xml

Si vemos el contenido del archivo 'src/main/resources/META-INF/spring/database.properties' debe lucir así:

database.password=yyyy
database.url=jdbc\:mysql\://localhost\:3306/roo_db_pojo
database.username=xxxx
database.driverClassName=com.mysql.jdbc.Driver

Muy bien, hasta aquí ya tenemos nuestro proyecto vacío el cual ya esta configurado para conectarse a una base de datos. Asi pues, lo siguiente es crear la base de datos (si aun no lo han hecho).

Ya con nuestra base de datos y nuestro proyecto de Spring Roo creado vamos a crear una tabla sencilla para almacenar personas:

CREATE TABLE `persona` (
  `id_persona` int(11) NOT NULL,
  `nombre` varchar(50) character set latin1 NOT NULL,
  `apellido` varchar(50) character set latin1 NOT NULL,
  PRIMARY KEY  (`id_persona`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci;

Si ejecutamos el comando para hacer ingeniería reversa como sigue:

roo> database reverse engineer --package com.jabaddon.roo.dbtopojo.dominio

Obtendremos lo siguiente:

Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona.java
Created com.jabaddon.roo.dbtopojo.dominio.Persona
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_Entity.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_DbManaged.aj
Managed SRC_MAIN_RESOURCES/META-INF/persistence.xml
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_Configurable.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_ToString.aj

La primera vez que se ejecute el comando de ingeniería inversa es necesario especificar el paquete en el cual las entidades serán creadas.

Como ven Roo ha creado una entidad Persona y ha generado los clásicos .aj derivados del archivo .java. Aunque existe un nuevo .aj llamado 'Persona_Roo_DbManaged.aj', este aspecto es el que contiene los campos de nuestra entidad que mapean a las columnas que Roo encontro en la tabla 'PERSONA'.

package com.jabaddon.roo.dbtopojo.dominio;

import java.lang.String;
import javax.persistence.Column;
import javax.validation.constraints.NotNull;

privileged aspect Persona_Roo_DbManaged {
    
    @Column(name = "nombre", length = 50)
    @NotNull
    private String Persona.nombre;
    
    @Column(name = "apellido", length = 50)
    @NotNull
    private String Persona.apellido;
    
    public String Persona.getNombre() {
        return this.nombre;
    }
    
    public void Persona.setNombre(String nombre) {
        this.nombre = nombre;
    }
    
    public String Persona.getApellido() {
        return this.apellido;
    }
    
    public void Persona.setApellido(String apellido) {
        this.apellido = apellido;
    }
    
}

Ahora supongamos que se nos olvido agregarle una columna a nuestra tabla PERSONA y en esa columna deseamos guardar la fecha de nacimiento.

Si agregamos la columna de fecha de nacimiento a nuestra tabla y corremos de nueva cuenta el comando 'database reverse engineer' obtendremos lo siguiente:

Managed ROOT/.roo-dbre
Managed SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_DbManaged.aj
Managed SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_ToString.aj

Y si abrimos el archivo 'Persona_Roo_DbManaged.aj' veremos que ya tiene un nuevo campo de fecha de nacimiento:

@Column(name = "fecha_nacimiento")
@NotNull
@Temporal(TemporalType.DATE)
@DateTimeFormat(style = "S-")
private Date Persona.fechaNacimiento;

Si se están preguntando ¿que pasa si yo agrego un campo al archivo Persona.java?, pues la respuesta es lo mismo que ha hecho Roo desde su primera version y es que simplemente regenerara los archivos .aj necesarios para que reflejen el nuevo campo. Por ejemplo si modificamos el archivo Pesona.java para agregarle una nueva propiedad 'nick':

package com.jabaddon.roo.dbtopojo.dominio;

import javax.persistence.Entity;
import org.springframework.roo.addon.javabean.RooJavaBean;
import org.springframework.roo.addon.tostring.RooToString;
import org.springframework.roo.addon.entity.RooEntity;
import org.springframework.roo.addon.dbre.RooDbManaged;
import javax.persistence.Table;

@Entity
@RooJavaBean
@RooToString
@RooEntity(versionField = "")
@RooDbManaged(automaticallyDelete = true)
@Table(name = "persona", catalog = "roo_db_pojo")
public class Persona {    
                     
 @NotNull
 @Column(name = "nick", length = 10)
 private String nick;
}

Al momento de salvar el archivo, Roo monitorea el cambio y genera el .aj JavaBean y administra el .aj ToString:

[Timer-0] Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_JavaBean.aj
[Timer-0] Managed SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_ToString.aj

Interesante, ¿no lo creen?

Hasta ahorita se creo una tabla muy sencilla que Roo fue capaz de detectar y generar una entidad a partir de la definición de la tabla, pero pongamos a prueba esta funcionalidad de Roo generando tablas con relaciones 1:N, N:1 y el N:M.

Para la relación 1:N, agregaremos otra tabla que represente los teléfonos de una persona y su debida relación con un Foreign key:

CREATE TABLE `telefono` (
  `id_telefono` int(11) NOT NULL,
  `numero` varchar(10) character set latin1 NOT NULL,
  `id_tipo_telefono` int(11) NOT NULL,
  `id_persona` int(11) NOT NULL,
  PRIMARY KEY  (`id_telefono`),
  KEY `id_persona` (`id_persona`),
  CONSTRAINT `fk_telefono2persona` FOREIGN KEY (`id_persona`) REFERENCES `persona` (`id_persona`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci; 

Y si ejecutamos de nueva cuenta el comando 'database reverse engineer' obtendremos:

Managed ROOT/.roo-dbre
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Telefono.java
Created com.jabaddon.roo.dbtopojo.dominio.Telefono
Managed SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_DbManaged.aj
Managed SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Persona_Roo_ToString.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Telefono_Roo_Entity.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Telefono_Roo_DbManaged.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Telefono_Roo_Configurable.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Telefono_Roo_ToString.aj

Roo a creado una nueva entidad Telefono y ha modificado la entidad Persona. Si abrimos los archivos Persona_Roo_DbManaged.aj y Telefono_Roo_DbManaged.aj:

NOTA: Voy a omitir los metodos get y set.

privileged aspect Persona_Roo_DbManaged {
    
    @OneToMany(mappedBy = "persona")
    private Set Persona.telefonoes;
    
    @Column(name = "nombre", length = 50)
    @NotNull
    private String Persona.nombre;
    
    @Column(name = "apellido", length = 50)
    @NotNull
    private String Persona.apellido;
    
    @Column(name = "fecha_nacimiento")
    @NotNull
    @Temporal(TemporalType.DATE)
    @DateTimeFormat(style = "S-")
    private Date Persona.fechaNacimiento;

    ....
}

privileged aspect Telefono_Roo_DbManaged {
    
    @ManyToOne
    @JoinColumn(name = "id_persona", referencedColumnName = "id_persona")
    private Persona Telefono.persona;
    
    @Column(name = "numero", length = 10)
    @NotNull
    private String Telefono.numero;
    
    @Column(name = "id_tipo_telefono")
    @NotNull
    private Integer Telefono.idTipoTelefono;
    
    ...
}

Perfecto! Roo ha relacionado las entidades de Persona y Telefono con un @OneToMany de Persona a Telefono y un @ManyToOne de Telefono a Persona.

Continuemos con la relación N:1 creando un catalogo para los tipos de telefono:

CREATE TABLE `cat_tipo_telefono` (
  `id_tipo_telefono` int(11) NOT NULL,
  `nombre` varchar(50) NOT NULL,
  PRIMARY KEY  (`id_tipo_telefono`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci; 

y modificando la tabla de Telefono para que tenga la relacion con su catalogo de tipo de telefono:

CREATE TABLE `telefono` (
  `id_telefono` int(11) NOT NULL,
  `numero` varchar(10) character set latin1 NOT NULL,
  `id_tipo_telefono` int(11) NOT NULL,
  `id_persona` int(11) NOT NULL,
  PRIMARY KEY  (`id_telefono`),
  KEY `index_id_persona` (`id_persona`),
  KEY `index_id_tipo_telefono` (`id_tipo_telefono`),
  CONSTRAINT `fk_telefono2persona` FOREIGN KEY (`id_persona`) REFERENCES `persona` (`id_persona`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT `fk_tipo2catalogo` FOREIGN KEY (`id_tipo_telefono`) REFERENCES `cat_tipo_telefono` (`id_tipo_telefono`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci;

De nueva cuenta si ejecutamos de nueva cuenta el comando 'database reverse engineer' obtendremos:

Managed ROOT/.roo-dbre
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/CatTipoTelefono.java
Created com.jabaddon.roo.dbtopojo.dominio.CatTipoTelefono
Managed SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Telefono_Roo_DbManaged.aj
Managed SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Telefono_Roo_ToString.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/CatTipoTelefono_Roo_Entity.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/CatTipoTelefono_Roo_DbManaged.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/CatTipoTelefono_Roo_Configurable.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/CatTipoTelefono_Roo_ToString.aj

Roo ha creado una entidad que CatTipoTelefono y modifico la entidad Telefono. Si abrimos todos los archivos Persona_Roo_DbManaged.aj, Telefono_Roo_DbManaged.aj y CatTipoTelefono_Roo_DbManaged.aj:

privileged aspect Persona_Roo_DbManaged {
    
    @OneToMany(mappedBy = "persona")
    private Set Persona.telefonoes;
    
    @Column(name = "nombre", length = 50)
    @NotNull
    private String Persona.nombre;
    
    @Column(name = "apellido", length = 50)
    @NotNull
    private String Persona.apellido;
    
    @Column(name = "fecha_nacimiento")
    @NotNull
    @Temporal(TemporalType.DATE)
    @DateTimeFormat(style = "S-")
    private Date Persona.fechaNacimiento;
    ...
}

privileged aspect Telefono_Roo_DbManaged {
    
    @ManyToOne
    @JoinColumn(name = "id_persona", referencedColumnName = "id_persona")
    private Persona Telefono.persona;
    
    @ManyToOne
    @JoinColumn(name = "id_tipo_telefono", referencedColumnName = "id_tipo_telefono")
    private CatTipoTelefono Telefono.catTipoTelefono;
    
    @Column(name = "numero", length = 10)
    @NotNull
    private String Telefono.numero;
    ...
}

privileged aspect CatTipoTelefono_Roo_DbManaged {
    
    @OneToMany(mappedBy = "catTipoTelefono")
    private Set CatTipoTelefono.telefonoes;
    
    @Column(name = "nombre", length = 50)
    @NotNull
    private String CatTipoTelefono.nombre; 
    ...
}

Muy interesante.

NOTA: Obviamente no es una buena idea que la entidad CatTipoTelefono tenga una colección de los teléfonos que tiene relacionados. Esto es algo que tiene que mejorar Spring Roo. Me llevo de tarea investigar si hay alguna forma de decirle a Roo que evite hacer esto.

Ahora vamos a ver como se comporta con una relacion N:M. Asi que, vamos a crear una tabla de Solicitudes, otra de documentos y una que defina los documentos que tiene una solicitud:

CREATE TABLE `solicitud` (
  `id_solicitud` int(11) NOT NULL,
  `folio` varchar(10) NOT NULL,
  PRIMARY KEY  (`id_solicitud`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `documento` (
  `id_documento` int(11) NOT NULL,
  `nombre` varchar(50) NOT NULL,
  PRIMARY KEY  (`id_documento`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1; 

CREATE TABLE `solicitud_documento` (
  `id_solicitud` int(11) NOT NULL,
  `id_documento` int(11) NOT NULL,
  PRIMARY KEY  (`id_documento`,`id_solicitud`),
  CONSTRAINT `fk_documento2documento` FOREIGN KEY (`id_documento`) REFERENCES `documento` (`id_documento`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT `fk_solicitud2solicitud` FOREIGN KEY (`id_solicitud`) REFERENCES `solicitud` (`id_solicitud`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci;

al correr el comando 'database reverse engineer' obtenemos:

Managed ROOT/.roo-dbre
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Documento.java
Created com.jabaddon.roo.dbtopojo.dominio.Documento
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Solicitud.java
Created com.jabaddon.roo.dbtopojo.dominio.Solicitud
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Solicitud_Roo_Entity.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Solicitud_Roo_DbManaged.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Solicitud_Roo_Configurable.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Solicitud_Roo_ToString.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Documento_Roo_Entity.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Documento_Roo_DbManaged.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Documento_Roo_Configurable.aj
Created SRC_MAIN_JAVA/com/jabaddon/roo/dbtopojo/dominio/Documento_Roo_ToString.aj

Roo ha creado las entidades Solicitud y Documento y si vemos los archivos Solicitud_Roo_DbManaged.aj y Documento_Roo_DbManaged.aj lucen asi:

privileged aspect Solicitud_Roo_DbManaged {
    
    @ManyToMany(mappedBy = "solicituds")
    private Set Solicitud.documentoes;
    
    @Column(name = "folio", length = 10)
    @NotNull
    private String Solicitud.folio;
    
    ...
}   

privileged aspect Documento_Roo_DbManaged {
    
    @ManyToMany
    @JoinTable(name = "solicitud_documento", joinColumns = { @JoinColumn(name = "id_documento") }, inverseJoinColumns = { @JoinColumn(name = "id_solicitud") })
    private Set Documento.solicituds;
    
    @Column(name = "nombre", length = 50)
    @NotNull
    private String Documento.nombre;
    
    ...
} 

Roo detecto la relación N:M entre Solicitud y Documento y puso una relaciones @ManyToMany en las entidades utilizando como @JoinTable la tabla SOLICITUD_DOCUMENTO.

Por ultimo, veamos que hace el comando 'database introspect':

roo> database introspect --schema roo_db_pojo

El comando 'database introspect' pide como argumento el esquema de la base de datos y nos da como salida:

Roo tiene almacenado la estructura de la base de datos en el archivo ROOT/.roo-dbre (este archivo apareció varias veces al ejecutar el comando 'database reverse engineer').

Muy interesante y util esta funcionalidad de poder hacer ingenieria reversa de una base de datos existente con Spring Roo.

Creo que es todo para este post, por favor comenten.