Ver Mensaje Individual
  #4 (permalink)  
Antiguo 21/11/2014, 13:21
Avatar de HackmanC
HackmanC
 
Fecha de Ingreso: enero-2008
Ubicación: Guatemala
Mensajes: 1.817
Antigüedad: 16 años, 10 meses
Puntos: 260
Sonrisa Respuesta: Join Criteria JPA

Hola,

Posiblemente todavía sigo sin entender, pero como dije anteriormente posiblemente te sea de alguna ayuda,

Cita:
Iniciado por jlgarcia1977 Ver Mensaje
Si me he dado cuenta...
Código Java:
Ver original
  1. if (grupoAplicacion != null && !grupoAplicacion.isNewObject()) { <--grupoAplicacion que envió
  2.       Root<GrupoAplicacion> grupoAplicacionRot = query.from(GrupoAplicacion.class);....
Me confundió bastante el hecho que al parecer tu Entity grupoAplicacion, (que todavía no estoy seguro que sea un Entity, porque no se mira la definición), se ocultaba por la variable de tipo Root grupoAplicacion. Es decir, se llaman igual pero tiene diferente ámbito.

Para mi, es bastante confuso el concepto de lo que quieres hacer, aunque la idea que yo entendí parece simple según el enunciado. Yo no comprendo bien que es lo que necesitas saber, porque pareciera que no estas resolviendo el problema adecuadamente, pareciera que estas metiendo conceptos innecesarios pero al mismo tiempo pareciera que conoces bien de bases de datos y JPA.

Yo, en mi caso personal lo resolvería (lo que yo entendí) de la siguiente forma.

Tengo dos tablas Aplicaciones y GrupoAplicaciones, relacionadas, por uno o mas campos, y tengo una entidad GrupoAplicacionesEntity de la tabla GrupoAplicaciones, quiero todos los registros de Aplicaciones que sean iguales en la relación con GrupoAplicacionesEntity, y aparte quiero otra consulta de todos los registros de Aplicaciones que no sean iguales en la relación.

Entonces, ¿para que necesito la relación? si ya tengo toda la información necesaria para extraer las Aplicaciones que cumplan con GrupoAplicacionesEntity. Aplicaciones seguramente ya tiene los campos que relacionan con GrupoAplicaciones, solamente le pondría que sean iguales a GrupoAplicacionesEntity.

Por ejemplo, (algo así, yo uso un predicate para unir todo el where y se lo aplico al final, posiblemente tendrás que cambiar algunas o muchas cosas para que sea adapte a tu List<>):
Código Java:
Ver original
  1. Path<Integer> grupoID = root.get(Aplicaciones_.grupoId);
  2. predicate = cb.and(predicate, cb.equal(grupoID, GrupoAplicacionesEntity.id));
Si miras el SQL con un logger FINE (quedaría algo así):
Código SQL:
Ver original
  1. SELECT .. FROM Aplicaciones
  2. WHERE Aplicaciones.grupoID = 8
Esa consulta me devolvería todos los registros en Aplicaciones que tengan el mismo GrupoAplicaciones. Y en el otro caso usas cb.not(), te devolvería todo, menos el GrupoAplicaciones que le enviaste. Por eso yo no miro la necesidad del .join(), a menos que haya algo adicional como un LEFT JOIN, que es diferente. U otros motivos, que no sea un Entity, que no venga la información completa, que busques por un campo diferente que el grupoId, y un largo etc.

En ese caso posiblemente si necesites el .join(), pero aún así no miro la necesidad de crear otro Root. Solamente el .join() es necesario, y adicionalmente seleccionar el GrupoID con el .equals(), posiblemente con otro u otros campos del .join().

En base a lo que entendí es todo lo que puedo decir, sino posiblemente alguien mas que haya comprendido mejor podría ayudarte,

Saludos,

Última edición por HackmanC; 21/11/2014 a las 13:34 Razón: agregar otros motivos