Consulta Hibernate con parametros

[Nicolas Luna]

Hola, estoy comenzando con hibernate, tengo una tabla:

Usuario
-----------
id
nombre
email
----------

quiero hacer una consulta para que al intentar registrarse alguien chequee que no exista el nombre ni el mail en la BD.

Algo tipo "Select count(*) from Usuario u where u.name = (parametro1) OR u.email = (parametro2)"

algo asi y q me devuelve un true si existe algun caso.

Estuve mirando muy poco HQL

[Gunther Schneider]

Eso te devolveria un Integer con la cantidad de usuarios con ese
nombre o ese mail. Vos deberias ver que ese numero sea cero, si es
mayor a cero ya existe.

[Pablo Saavedra]

Básicamente sería esto:

String hql = "select count(u) from Usuario u where u.name = ? OR u.email = ?";

Query q = session.createQuery(hql);
q.setString(0,nombre);
q-setString(1,email);
List result = q.list();
if (result != null && !result.isEmpty())
  return true;

return false;

La otra opción es definir los campos como unique en tu mapeo, y dejar que al grabar reviente con una excepción de constraint violada.

Saludos,
Pablo.

[Pablo Saavedra]

Tenés razón, estaba pensando en otra cosa :).

Gracias.

[Pablo Saavedra]

Corrección:

On 23/02/07, Pablo Saavedra <pablo.a....@gmail.com> wrote:

Básicamente sería esto:

String hql = "select count(u) from Usuario u where u.name = ? OR u.email = ?";

Query q = session.createQuery(hql);
q.setString(0,nombre);
q-setString(1,email);

 

Integer result = (Integer) q.uniqueResult();
if (result != null && !result.iintValue() > 0)
  return true;

[Gunther Schneider]

Pablo, si lei bien hay un error en eso.
q.list() nunca devuelve null, pero bueno, eso es un detalle. El tema
esta en que vos devolves true si no esta vacio, pero vos estas
seleccionando el count, no los objetos que cumplen, entonces siempre
te va a devolver un solo elemento en la lista, si no hay ninguno sera
un 0, sino sera la cantidad.

Lo correcto seria:
List result = q.list();
int count = ((Number)q.get(0)).intValue(); // nunca me acuerdo que
subclase de Number devuelve :P
return count != 0; // asumiendo que el metodo tiene que devolver true si existe

Saludos!

[Pablo Saavedra]

Si, tenés razón pensé una cosa pero escribí otra. El check por null nunca me acuerdo si hace falta o no, así que por las dudas lo hago.

Gracias,
Pablo.

On 23/02/07, Gunther Schneider <gunt...@gmail.com> wrote:

[Sam]

Buenas, ya que salió el tema, tengo una duda recurrente al respecto,
quisiera saber que estrategias han adoptado para este tipo de
consultas.

Suponiendo que tenemos una aplicación prolijita, "de libro de texto",
con spring manejando las transacciones y la persistencia con DAOs que
encapsulen hibernate... la cuestión sería: dónde meto una consulta de
este tipo, como saber si el mail esta disponible, o similares?

Si el diseño de la aplicación consiste en trabajar cada objeto del
modelo con su respectivo DAO (load, save, delete, etc...), ¿qué se
hace con las consultas que no cargan un objeto sino que devuelven
true/false o cálculos (ej, total de usuarios)? se crean "miniobjetos"
que las representan con su propio DAO? o métodos ad-hoc en el DAO que
mas se aproxime conceptualmente y que devuelvan el tipo de dato
primitivo que corresponda a la ocasión?

Cuáles son las soluciones que se utilizan normalmente?

[Gunther Schneider]

Al DAO o a un servicio. En general si implica hacer una consulta a la
base yo lo pongo en el DAO. Justamente el DAO encapsula el acceso a
datos, y yo no quiero saber desde afuera si accedo a traves de HQL,
SQL, o una estructura en memoria, entonces le pregunto eso al DAO y
permito que el lo resuelva.

En todo caso puedo ponerlo en el servicio y que este delegue la
operacion de consulta al DAO. Asi como una busqueda por cierto
criterio la pondria en el DAO, contar cuantos cumplen un criterio
tambien lo pondria ahi.

Saludos

[as1]

Yo no sé cuando dicen DAO a que se refieren, pero creo que la solucion
es aplicar un patron de Facade. Yo uso Toplink y cuando tengo el mapeo
de las tablas a objetos despues me creo un facade para hacer todo tipo
de operaciones con ese mapeo, lo basico de ABM(Alta, Baja,
Modificacion) y todo esto de saber si ya hay algun registro. Yo en
particular depende de la infraestructura tambien hago que este facade
sea un EJB, en el caso de tener tres capas de servidores que el manejo
de esos servicios toplink los necesite desde varios programas que
estan en otros equipos, lo necesite varias veces.

DBMS -> Toplink -> POJOS -> EJB

POJOS => (Plain Old Java Objects)

Los EJB los vuelvo a utilizar desde aplicaciones distribuidas en la
red que trabajan sobre el mismo modelo de datos.

On 23 feb, 14:54, "Gunther Schneider" <gunth...@gmail.com> wrote:
> Al DAO o a un servicio. En general si implica hacer una consulta a la
> base yo lo pongo en el DAO. Justamente el DAO encapsula el acceso a
> datos, y yo no quiero saber desde afuera si accedo a traves de HQL,
> SQL, o una estructura en memoria, entonces le pregunto eso al DAO y
> permito que el lo resuelva.
>
> En todo caso puedo ponerlo en el servicio y que este delegue la
> operacion de consulta al DAO. Asi como una busqueda por cierto
> criterio la pondria en el DAO, contar cuantos cumplen un criterio
> tambien lo pondria ahi.
>
> Saludos
>

> On 2/23/07, Sam <samanta.fernan...@gmail.com> wrote:
>
>
>
> > Buenas, ya que salió el tema, tengo una duda recurrente al respecto,
> > quisiera saber que estrategias han adoptado para este tipo de
> > consultas.
>
> > Suponiendo que tenemos una aplicación prolijita, "de libro de texto",
> > con spring manejando las transacciones y la persistencia con DAOs que
> > encapsulen hibernate... la cuestión sería: dónde meto una consulta de
> > este tipo, como saber si el mail esta disponible, o similares?
>
> > Si el diseño de la aplicación consiste en trabajar cada objeto del
> > modelo con su respectivo DAO (load, save, delete, etc...), ¿qué se
> > hace con las consultas que no cargan un objeto sino que devuelven
> > true/false o cálculos (ej, total de usuarios)? se crean "miniobjetos"
> > que las representan con su propio DAO? o métodos ad-hoc en el DAO que
> > mas se aproxime conceptualmente y que devuelvan el tipo de dato
> > primitivo que corresponda a la ocasión?
>
> > Cuáles son las soluciones que se utilizan normalmente?
>

> > On 2/23/07, Pablo Saavedra <pablo.a.saave...@gmail.com> wrote:
> > > Si, tenés razón pensé una cosa pero escribí otra. El check por null nunca me
> > > acuerdo si hace falta o no, así que por las dudas lo hago.
>
> > > Gracias,
> > > Pablo.
>

> > > On 23/02/07, Gunther Schneider <gunth...@gmail.com> wrote:
>
> > > > Pablo, si lei bien hay un error en eso.
> > > > q.list() nunca devuelve null, pero bueno, eso es un detalle. El tema
> > > > esta en que vos devolves true si no esta vacio, pero vos estas
> > > > seleccionando el count, no los objetos que cumplen, entonces siempre
> > > > te va a devolver un solo elemento en la lista, si no hay ninguno sera
> > > > un 0, sino sera la cantidad.
>
> > > > Lo correcto seria:
> > > > List result = q.list();
> > > > int count = ((Number)q.get(0)).intValue(); // nunca me acuerdo que
> > > > subclase de Number devuelve :P
> > > > return count != 0; // asumiendo que el metodo tiene que devolver true si
> > > existe
>
> > > > Saludos!
>

> > > > On 2/23/07, Pablo Saavedra <pablo.a.saave...@gmail.com > wrote:
> > > > > Básicamente sería esto:
>
> > > > > String hql = "select count(u) from Usuario u where u.name = ? OR u.email
> > > =
> > > > > ?";
>
> > > > > Query q = session.createQuery (hql);
> > > > > q.setString(0,nombre);
> > > > > q-setString(1,email);
> > > > > List result = q.list();
> > > > > if (result != null && !result.isEmpty())
> > > > > return true;
>
> > > > > return false;
>
> > > > > La otra opción es definir los campos como unique en tu mapeo, y dejar
> > > que al
> > > > > grabar reviente con una excepción de constraint violada.
>
> > > > > Saludos,
> > > > > Pablo.
>