El establecer relaciones adecuadas en nuestra aplicación no solo es buena práctica, sino que es esencial para la funcionalidad y eficiencia de cualquier proyecto. Hoy exploraremos cómo se pueden crear relaciones en un modelo de datos usando anotaciones de JPA, que ayudarán a mantener la integridad de nuestros datos, mejorar el rendimiento de la aplicación y hacer el código más legible y mantenible.
¿Cuál es la relación entre categorías y productos?
En nuestro modelo de datos, una categoría puede tener muchos productos. Esto en JPA se traduce de la siguiente forma:
Clase Producto:
Se añade un atributo privado de tipo Categoría.
Se utilizan dos anotaciones: @ManyToOne y @JoinColumn.
Este enfoque de creación de relaciones no solo mantiene la integridad de datos, sino que permite sacar el máximo provecho de Java y de sus herramientas modernas. Siempre es clave mapear las relaciones necesarias, ayudando a la optimización del desempeño de la aplicación sin agregar complejidades innecesarias.
Con el modelo de datos correctamente mapeado, nuestro próximo paso será interactuar con la base de datos utilizando los repositorios de Spring Data. Este es un camino emocionante hacia una aplicación más robusta y eficiente. ¡Te alentamos a seguir aprendiendo y explorando!
me tome la molestia de ir al ultimo video y ver si ya lo habia corregido en los archivos adjuntos y efectivamente luego lo corregira, lo expongo mas que nada para que nadie se sienta frustrado de no entender algo que en realidad esta mal.
Estaba apunto de revisar la clase de nuevo, gracias
En el diagrama de la base de datos la relación que se ve entre las tablas COMPRAS y COMPRAS_PRODUCTOS es de UNO a UNO; sin embargo, en el momento de hacer la relación en código se realiza como UNO a MUCHOS, mostrando posiblemente un error en la relación en el diagrama.
Lo comento por si a alguien le quedó la duda. 😁
Gracias por comentarlo Manuel, es posible que algo se nos haya escapado en edición. Efectivamente la relación entre COMPRAS y COMPRAS_PRODUCTOS debe ser de UNO a MUCHOS porque una compra puede tener muchos productos.
Vamos a corregirlo!
El error del diagrama en pantalla ya fue corregido. Muchas gracias por comentarlo. 🙌💚
A lo entendí
Cuando una tabla tiene un foreign key se usa JoinColumn y en la tabla de donde se origina ese foreign key se usa dentro de la relacion el mappedBy con el nombre del atributo de la clase donde se uso el JoinColumn.
si senor
Definitivamente un profesor excelente.
x2
totalmente de acuerdo
En la última relación @OneToMany debería ir "compra" en el mappedBy, y no "producto", ya que se está asociando Compra con ComprasProducto, indicando que una compra puede tener muchos productos.
Justo estaba por comentar lo mismo 🧐
Es cierto!! lo noté, pero no sé si sé puede hacer esa relación o es cómo tu dices.
min. 5:10 quiso decir "Un cliente pertenece a muchas compras"
Gracias
Gracias, me había confundido cuando dijo eso jajaja.
Es una cosa hermosa, creo que esto simplifica mucho lo que yo conocía hace 10 años =P
Excelente clases , me gusta spring boot y estas clases se dejan entender muy bien.
Dejo un aporte, actualmente existe algo llamado JPA Tools que facilita todo lo que Alejandro explico en los últimos 3 videos, cabe aclarar que es importante saber como hacerlo manual y paso a paso para entender las cosas con mas claridad, tengo un pequeño manual que hice yo mismo si alguien le interesa me escriben.
Muchas gracias por tu aporte Jorge, en lo personal uso JPA Tools o procesos de generación automática de entities cuando tengo demasiadas tablas para generar (Aunque siempre con cuidado de luego ver que si necesito y que no, con el fin de no generar atributos o relaciones innecesarias).
Estoy seguro de que toda la comunidad estaría feliz de ver tu manual. ¿Qué te parece si nos compartes el enlace aquí?
Hola Jorge, gracias por tus aclaraciones, seria muy bueno que nos compartas el resumen que nos comentas, gracias ante todo.
Chicos, algo que se le pasó al profesor fue crear los Setters y Getters de esos nuevos atributos con los que se crea la relación entre entidades, deben agregarlos para que en clases posteriores no tengan problemas, ya que de no hacerlo en la clase 27 cuando quieran probar la API saldrá un error en unknow justo con estos atributos agregados en esta clase:
error:Unknown property "productos"in result type Categoria.
No olviden poner los metodos GET y SET de las nuevas variables creadas.
Y como seria cuando la relacion es 1 a 1?? tengo que poner anotaciones en ambas clases??
Yep. Tendrías que ponerlo en ambas clases. Te dejo esta guía donde te explican cómo hacerlo.
Esta claro, pero hay que practicarlo porque son varios pasos interconectados
Puede ser que haya faltado actualizar los get y los set de las relaciones? En la próxima clase apenas empieza en pantalla se ve que lo ha hecho pero no se aclara.
¿Por qué agrega cómo atributo el idCliente y luego el cliente, no sería innecesario el idCliente ?
En ocasiones necesitamos los dos. En este caso puntual usamos el atributo cliente cuando recuperamos la información porque aquí se incluye toda la información completa del cliente.
Sin embargo, para guardar una nueva compra necesitamos incluir el cliente y como ese atributo tiene insertable = false, updatable = false no podemos hacerlo desde ahí; por eso es necesario el idCliente para usarlo cuando queramos almacenar o modificar una compra.
Una pregunta, en la ultima relacion de Compra a ComprasProducto
el mappedBy va hacia el parametro "producto" y no "compra" de la clase ComprasProducto, si en teoria yo estoy diciendo que me de todas las compras productos asociadas a mi identidad, y mi identidad en ComprasProducto es "compra", no "producto"
Por ende la relacion no deberia ser hacia "compras" ?
Lo mismo pense, pero quise venir a los comentarios a ver si estaba en lo correcto hasta que vi tu comentario, creo que SI es asi, con referencia a “compra” y NO a “producto”.
Tengo una pregunta: Así como generamos Getters and Setters para las variables privadas de las columnas, debemos generarlos también para las variables privadas de tipo 'Categoria', 'Producto'?, y de no ser necesario, por qué?.
El get es necesario para poder acceder al campo privado y el set debe ser creado en función de la necesidad que tengas para asignar un valor a dicho campo.
Para esos campos también es necesario crear el get para poder acceder a su valor y el set es necesario siempre y cuando queramos modificar o asignar un valor a dichos atributos.
Si tenemos una tabla productos con 100000 registros y 20000 productos tienen la categoria 1, el atributo lista de producto de la clase Categoria se llenará con 20000 registros? No me quedó claro la finalidad de tener ese atributo
Es correcto. La forma en que mapeamos esta relación permitiría que teniendo una categoría podamos obtener todos los productos que le pertenezcan.
Este tipo de relaciones deben ser creadas siempre respondiendo a la pregunta "¿De verdad necesito esta relación?" porque claramente pueden existir relaciones innecesarias que afecten el rendimiento y la gestión de memoria de nuestra aplicación.