Spring Data, accediendo fácilmente a cualquier almacén de datos

Spring Data es un proyecto SpringSource cuyo propósito es unificar y facilitar el acceso a diferentes tipos de almacenes de persistencia, tanto en los sistemas de bases de datos relacionales y almacenes de datos NoSQL.

Cada subtipo de proyecto dependiente del alamacen de datos se caracterizan por ofrecer CRUD (Create-Read-Update-Delete), métodos de búsqueda, clasificación y paginación. Spring Data proporciona interfaces genéricas para estos aspectos (CrudRepository, PagingAndSortingRepository), así como implementaciones de persistencia específica.

Podemos extender las interfaces como lo hacemos para nuestros daos de hibernate o jpa:


public interface UserRepository extends MongoRepository<User, String> {
        @Query("{ fullName: ?0 }")
        List<User> findByTheUsersFullName(String fullName);
        List<User> findByFullNameLike(String fullName, Sort sort);
}
...

Para los proyectos Neo4J y MongoDB; spring data nos ofrece Templates. Que nos permiten hacer operaciones de CRUD, busquedas Pero todos estos métodos funcionan sólo para el almacén de datos configurado. Spring Data JPA no ofrece Templates dado que EntityManager es como un template.

Para configurar un template lo podemos hacer de este modo:

Dependiente de la tecnología que utilicemos para almancenar datos podemos anotar nuestros objetos. Cada tipo de almacén de datos viene con su propio conjunto de anotaciones para proporcionar la meta información necesaria para la asignación. Vamos a ver cómo un usuario de dominio objeto simple se pueden asignar a los almacenes de datos:

JPA	MongoDB	Neo4j
@Entity @Table(name="TUSR") public class User {   @Id   private String id;   @Column(name="fn")   private String name;   private Date lastLogin; ... }	@Document( collection="usr") public class User {   @Id   private String id;   @Field("fn")   private String name;   private Date lastLogin;  ... }	@NodeEntity public class User {   @GraphId   Long id;   private String name;   private Date lastLogin; ... }

Todo aquel que este familiarizado con las anotaciones de de JPA puede, utilizar sin problemas las anotaciones de los otros almacenes de datos. 

Algo muy importante es que Spring Data provee QueryDsl para las consultas a repositorios JPA, MongoDb y Neo4J. QueryDsl permite generar consultas por medio de un dsl de forma muy fácil.

No hay ninguna API general a todos los almacenes de persistencia. Las diferencias son demasiado fundamentales. Pero el proyecto de datos Spring proporciona un modelo de programación común para acceder a sus datos.

Dejo link:

http://www.infoq.com/articles/spring-data-intro
http://www.springsource.org/spring-data

MongoDB + Spring Data

Ya hablamos bastante de spring data y también de mongoDB. El proyecto Spring Data intenta facilitarnos el acceso a diferente repositorios de datos. En esta oportunidad vamos a hablar de como nos facilita el acceso y manejo de la base de datos noSQL MongoDB.

Recordemos que MongoDB es una base documental, clave-valor; escrita en c++. Es conocida como la MySQL de las bases NoSQL. Dado que es liviana, muy usada y fácil de usar.

Spring Data nos provee:

• Configuración basada en Spring con XML o anotaciones
• MongoTemplate nos brinda la principales funcionalidades que se pueden aplicar a la base MongoDB.
• Traducción de las excepciones a excepciones más amigables.
• Mapeos de objetos integrados con Spring's Conversion Service
• Querys, criterias y DSLs basados en java.
• Implementaciones de interfaces de repositorio con métodos comunes.
• Integración con QueryDSL!!
• Persistencia cross-store; soporta entidades de JPA
• Log4j
• Integración con Map-Reduce
• Monitorización y administración basado en JMX 

Para utilizar esta herramienta con maven es necesario agregar el siguiente repositorio:

    spring-milestone
    Spring Maven MILESTONE Repository
    http://maven.springframework.org/milestone

y la siguiente dependencia:

 org.springframework.data
 spring-data-mongodb
 1.0.0.RC1
 

Dejo links:
http://www.springsource.org/spring-data/mongodb
http://static.springsource.org/spring-data/data-document/docs/current/reference/html/

CriteriaQuery de JPA vs Criteria de Hibernate vs QueryDSL

Estuve leyendo sobre la API de Criteria de JPA, y la verdad es que no me gusto.

Vamos por parte porque usar esta API? Porque nos provee la seguridad por tipo; escribiendo hql o ejbql por ejemplo tenemos el problema que al modificar un objeto; las consultas no se enteran y por lo tanto pueden explotar. Este problema se podría atacar haciendo una buena batería de test y ir corriéndola con maven por ejemplo. Pero lo ideal es que al modificar la clase se rompa donde esta siendo usada esa propiedad de esta manera el programa no compila hasta que no solucione todo. A la vez las herramientas de refactor me podrían ayudar modificando las consultas.

Veamos un ejemplo de criteria con JPA:

CriteriaQuery criteria = builder.createQuery( Person.class );
Root personRoot = criteria.from( Person.class );
criteria.select( personRoot );
criteria.where( builder.equal( personRoot.get( Person_.eyeColor ), "brown" ) );
List people = em.createQuery( criteria ).getResultList();

Esto en hql seria: from Person p where p.eyeColor = 'brown' (un poco mas fácil) Pero porque tanta cosa? Veamo el ejemplo de JPA, antes que nada necesitamos crear un builder de la query luego con ese builder creamos la query donde le decimos lo que vamos a consultar y que vamos a seleccionar y luego con el builder agregamos la condición. Cuando agregamos la condición (si fueron observadores) vieron que llama a una clase Person_ esta clase es la que contiene la metainformación de la clase y obviamente hay que programarla seria algo así:

import javax.persistence.metamodel.SingularAttribute;
import javax.persistence.metamodel.SetAttribute;
import javax.persistence.metamodel.StaticMetamodel;

@StaticMetamodel( Person.class )
public class Person_ {
    public static volatile SingularAttribute id;
    public static volatile SingularAttribute name;
        public static volatile SingularAttribute eyeColor;
    public static volatile SingularAttribute age;
    public static volatile SingularAttribute address;
    public static volatile SetAttribute orders;
}

Luego de hacer todo eso no me acuerdo que estoy consultando. Hay cosas que muy fácilmente se podrían mejorar como por ejemplo no puede suponer que lo que consultamos es lo que debe seleccionar? Todo hay que decirle!

Veamos como se puede hacer la consulta con Criteria de Hibernate:

List people = sess.createCriteria(Person .class).add( Restrictions.eq("eyeColor", "brown") ); 

Bastante más fácil pero se puede ver un pequeño problema si yo cambio en mi clase la propiedad "eyeColor" esta consulta va a seguir compilando pero va explotar cuando la ejecute. Ahora veamos como podríamos hacer esto con QueryDSL:

JPAQuery query = new JPAQuery(em);
QPerson p = new Qperson("p");
query.from(p).where(p.eyeColor.eq("brown"));

QueryDSL genera un tipo para consultar con el nombre Qperson que sería como este:

public class QPerson extends EntityPathBase{
…
}

Como conclusión podemos decir que es complejo hacer consultas de forma tipada y que queden bien es más complejo aun. De igual forma la API de Criteria de JPA se podria mejorar mucho más. Y esto se ve cuando miramos proyectos que nacieron para simplificar esta API como QueryDSL.

Escribiendo sql más fácil con Querydsl

No les pasa que cuando escriben hql les da miedo de equivocarse en el nombre de alguna propiedad o algo que pueda hacer explotar la aplicación? Cuando escriben consultas con criterios de hibernate, no les pasa que no saben como se deben hacer ciertas cosas o tienen que mirar el manual? No les parece poco intuitiva la API de Critera de hibernate?

Si a todo contestaste que si Querydsl es para vos. Querydsl es un framework el cual permite construir consultas type-safe muy similares a Sql para multiples formas de acceder a datos JPA, JDO y SQL.

En lugar de escribir consultas en texto  lo escribimos con este dsl de forma fluida y segura.

Que ventajas tiene usar Querydsl?

• Nos puede ayudar la IDE a escribir nuestras consultas, porque son propiedades. 
•  Contamos con la seguridad por tipo 
• Si refactorisamos nos permite refactorisar la consulta y si se rompe alguna consulta no compila. 
• Es más fácil escribir consultas complejas 
• Podemos escribir SQL o usarlo con Hibernate y también con MongoDB

Veamos un ejemplo de consulta:

query.from(customer)
    .where(customer.firstName.eq("Bob").and(customer.lastName.eq("Wilson")));

query.from(cat)
    .innerJoin(cat.mate, mate)
    .leftJoin(cat.kittens, kitten)
    .list(cat);

query.from(cat)
    .leftJoin(cat.kittens, kitten)
    .on(kitten.bodyWeight.gt(10.0))
    .list(cat);

query.from(customer)
    .orderBy(customer.lastName.asc(), customer.firstName.desc())
    .list(customer);

Se integra con Hibernate, maven, y también con Spring Data JPA. Además lo podemos usar con MongoDB y también con Scala.

Es de licencia Apache 2.

Dejo un video:



Dejo links:
http://www.querydsl.com/
http://www.querydsl.com/documentation
http://blog.mysema.com/2010/07/querying-hibernate-with-querydsl.html
http://blog.mysema.com/2010/11/mongodb-with-querydsl.html