Estoy en una posición en la que nuestra empresa tiene un servicio de búsqueda de bases de datos que es altamente configurable, por lo que es muy útil para configurar consultas de forma programática. La API de Criteria es potente, pero cuando uno de nuestros desarrolladores refactoriza uno de los objetos de datos, las restricciones de los criterios no indicarán que están rotos hasta que ejecutemos nuestras pruebas unitarias o, peor aún, en vivo y en nuestro entorno de producción. Recientemente, tuvimos un proyecto de refactorización esencialmente doble en tiempo de trabajo inesperadamente debido a este problema, una brecha en la planificación del proyecto que, si hubiéramos sabido cuánto tiempo realmente tomaría, probablemente hubiéramos tomado un enfoque alternativo.¿Cómo superar las limitaciones de los criterios de Hibernate y las API de ejemplo?
Me gustaría utilizar el API de ejemplo para resolver este problema. El compilador de Java puede indicar en voz alta que nuestras consultas están modificadas si estamos especificando las condiciones 'donde' en las propiedades reales de POJO. Sin embargo, solo hay mucha funcionalidad en la API de ejemplo y es limitante de muchas maneras. Tomemos el ejemplo siguiente
Product product = new Product();
product.setName("P%");
Example prdExample = Example.create(product);
prdExample.excludeProperty("price");
prdExample.enableLike();
prdExample.ignoreCase();
Aquí, la propiedad "nombre" se está consultando contra (donde nombre como 'P%'), y si tuviera que quitar o cambiar el nombre del campo "name", que sabría al instante . Pero, ¿qué pasa con el "precio" de la propiedad? Se está excluyendo porque el objeto Producto tiene un valor predeterminado para él, por lo que estamos pasando el nombre de la propiedad "precio" a un filtro de exclusión. Ahora, si se eliminó el "precio", esta consulta sería sintácticamente inválida y usted no lo sabría hasta el tiempo de ejecución. COJO.
Otro problema - ¿y si añadimos una segunda cláusula where:
product.setPromo("Discounts up to 10%");
Debido a la llamada a enableLike(), este ejemplo coincidirá en el texto promocional, "Descuentos de hasta el 10%", sino también "Descuentos de hasta 10,000,000 de dólares" o cualquier otra cosa que coincida. En general, las modificaciones de toda la consulta del objeto Ejemplo, como enableLike() o ignoreCase() no siempre serán aplicables a cada propiedad que se comprueba.
Aquí hay un tercer y más importante problema: ¿qué hay de otros criterios especiales? No hay forma de obtener cada producto con un precio superior a $ 10 utilizando el marco de ejemplo estándar. No hay forma de pedir resultados por promoción, descendiendo. Si el objeto Producto se unió a algún fabricante, tampoco hay forma de agregar un criterio al objeto fabricante relacionado. No hay forma de especificar con seguridad FetchMode en los criterios para el fabricante (aunque esto es un problema con la API Criteria en general, las relaciones buscadas no válidas fallan silenciosamente, incluso más una bomba de tiempo)
Por todo lo anterior Por ejemplo, debería volver a la API de Criteria y usar representaciones de cadenas de propiedades para realizar la consulta, una vez más, eliminando el mayor beneficio de las consultas de Ejemplo.
¿Qué alternativas existen para la API de ejemplo que puede obtener el tipo de asesoramiento en tiempo de compilación que necesitamos?
Esto es algo muy interesante, pero stackoverflow no es un foro de discusión, no recibirá comentarios aquí y su pregunta probablemente se cerrará en su forma actual. Como se menciona en las preguntas frecuentes, * "también está perfectamente bien hacer y responder su propia pregunta, siempre y cuando finja que está en Jeopardy: frasee en forma de pregunta" *. Sugiero reformularlo y publicar los detalles como respuesta. –
@Pascal gracias, voy a seguir adelante y volver a formatear la pregunta –
De nada. Y gracias por publicar esto. –