Consultas avanzadas con Query Methods en Spring Data
Contenido del curso
Cesar Jesus Gtz
Hinder Adrian Alvarez Perlaza
Jean Nuñez
german rodrigo sanz brekes
Rolando Mamani Salas
RAQUEL MARISOL
Ramón José París González
Joan José Roca Hormaza
Cristobal Vega
Rolando Mamani Salas
Israel Romero Garcia
ROMMEL DUAREZ SAENZ
Héctor Avilés
Edward Fernandez
Ricardo Exequiel De Angelis
Fernando Marcel Ovelar Mereles
Junior Aguilera
Felipe de Jesús Galindo Aguilar
geerson hugo pizarro mendivil
Alejandro Ramírez
Profesor
Alan Lapierre
Luis Brandon Flores González
Julian Sanchez
Cesar Lozano Rodriguez
Juan Calderón
David Gallego
Eduard Arias
Alejandro Rico García
Favio Amarilla Miño
Israel Camacho
Carlos Alberto Gonzalez Rembao
Osvaldo Garcia
Genial estos apuntes que haces. Deberías tenerlos en Git Hub o algún lugar centralizado.
Buen aporte, gracias
Creo que de la ruta de Java es sin dudas el mejor curso, se entiende a la perfeccion lo que expica Alejandro y Java Spring es realmente sorprendente..
Verdad que si
De acuerdo contigo, de todos los que he visto, este si que me ha gustado.
Los query method son muy potentes. Además de los explicado, permiten realizar múltiples operaciones de comparación con:
Existen más funcionalidades ✌🏼. Pueden ver más detalle acá: https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.query-methods.query-creation
gracias por tu aporte. :)
Si quieren aprender más sobre los Optionals les recomiendo esta clase:
https://platzi.com/clases/1826-java-funcional/26239-la-clase-optional/ :rocket:
Sera mi proxima clase... muchas gracias
Lo que no me gusta es que lleva buen rato escribiendo un montón de código y no ha probado nada para ver si funciona
no funciona porque le falta la anotación @Autowired
Muy interesante el tema sin duda :D, pero recuerden que no es una buena práctica de seguridad utilizar en su código Querys, lo mejor para consumir bases de datos son Stored Procedures para evitar ataques SQL Injection entre muchos otros.
ProductoCrudRepository
Optional<List<Producto>> findByPrecioVentaLessThanAndIdCategoriaOrderByNombreAsc(int precioVenta, int idCategoria);
ProductoRepository
public Optional<List<Producto>> getProductoByPrecioVentaLessThanPriceAndByCategory (int precioVenta, int idCategoria) { return productoCrudRepository.findByPrecioVentaLessThanAndIdCategoriaOrderByNombreAsc(precioVenta, idCategoria); }
Para que necesitaría buscar precios?
busca productos que su precio de venta sea inferior al solicitado y ordena por categoria
Sin duda el mejor curso que he visto en platzi...
Estos son los métodos que agregué a la clase Compra.
La clase estuvo muy buena, pero me quedó una duda acerca de porqué utiliza el optional y cual es el proposito de esta?
El uso del Optional es para demostrar que los Query Methods soportan este tipo de retorno que nos permite darle un enfoque funcional a nuestra aplicación. Te recomiendo el curso de Programación Funcional que tenemos aquí en Platzi, específicamente la clase donde hablan del Optional para que observes todo el potencial que tiene esta funcionalidad.
Gran curso, aun al día de hoy, si bien lo habia visto anteriormente y trabajo como desarrollador Java me sirve de base para un side project. Se aprecia la arquitectura orientada al dominio, es un buen punto de partida para empezar a construir algo.
Se pueden usar Query Methods o de manera nativa, pero es preferible la primera.
Los query methods son muy prácticos, son fáciles de usar y cómodos. Pero por favor, no los utilicen para queries complejas aunque funcione. He visto query methods con más de 100 caracteres de nombre, muy ilegibles, preferible utilizar JPQL y poner un nombre amigable.
me parece bien potente esto de los Query Methods, sin embargo pienso que hacer un refactor - que muchas veces implica mejorar los nombres de nuestros atributos - provocaria que se caiga el/los Query Method(s) cuyo nombre esta asociado a dicho atributo, y esto ocurriria sin siquiera saberlo ya que el compilador no detectaria dicho metodo como erroneo, este error seria solo detectado en runtime.
Buen apunte, compañero
Optional<List<Producto>> findByPrecioVentaGreaterThanEqualAndCantidadStockLessThanOrderByNombre(double precioVenta, int cantidadStock);
A mi en lo personal me gusta @Query porque siento mucho mas control sobre las consultas que se realizan en los métodos. Sin embargo, he notado que usar los Query Methods nos ahorra mucho trabajo en ciertas zonas y lo he empezado a utilizar con más frecuencia en mis proyectos. :rocket:
Una variante extra a @Query es: @NamedQuery
Se declara así:
@Entity @NamedQuery(name = "User.findByEmailAddress", query = "select u from User u where u.emailAddress = ?1") public class User { }
y se usa así:
public interface UserRepository extends JpaRepository<User, Long> { List<User> findByLastname(String lastname); User findByEmailAddress(String emailAddress); }
Por una experiencia personal les recomiendo a todos aplicar una una buena practica que es la de definir el tipo de dato para los id, ya sean variables o parámetros de métodos colocar como Long, ya que en sistemas de la vida real con muchísimos datos puede llegar a causarles problemas.
La respuesta siempre va a ser "depende"; dos mil ciento cuarenta y siete millones de registros o valores únicos son más que suficientes para la mayoría sistemas de medianos a grandes, si habrá situaciones particulares que requerirás más, o en sistemas distribuidos quizás un UUID sea lo más conveniente, pero yo estoy mas en pro de hacer un buen uso de los recursos tanto de BD como de memoria, al final el diseño lo define considera siempre el crecimiento.
Muy buen tema. gracias por explicarlo tan claro!
profesor! muchas gracias por la manera de explicar! me ha quedado super claro y quede muy intrigado con saber mas acerca de los query methods
