Consulta

En realidad este es un tema conceptualmente bastante complejo como para poder resumirlo en un foro de Europio Engine, pero voy a tratar de sintetizarlo lo más posible.

Según la teoría purista de objetos no existe requerimiento que pueda exigir "filtrar" objetos con el mismo concepto que se hace en las interfaces de manipulación de bases de datos (sistemas tradicionales), ya que aquello que para una base de datos se filtra con un "WHERE" en los objetos se resuelve con herencia, pertenencia o dependencia. Es decir que mientras una tabla A con un campo B y otro C es "seleccionada" según el valor de sus dos campos, en los Objetos existirá un Objeto A perteneciente a un objeto B que dependa de uno C (por ejemplo, claro que también podría tratarse de un Objeto B y otro C heredados de un Objeto A abstracto). Según esta teoría, un diseño puro de objeto jamás podría requerir el filtrado de datos en el sentido que se lo hace en el diseño de bases de datos, ya que el tipo de objetos ES el filtro puramente dicho.

Europio Engine se basa en este teoría. No obstante, incorpora ciertas herramientas que permiten hacer una manipulación básica de datos a través de la clase DataHandler (http://wiki.europio.org/virtualbooks/section/ver/9). Por ejemplo:

El método get_latest(N), que retorna los últimos N registros almacenados, para lo cual ordena los registros por ID desc. Definitivamente esto no creo que te sea de utilidad.
http://wiki.europio.org/virtualbooks/bookpage/ver/11

Luego, filter() y filter_like() permiten efectuar búsquedas por coincidencias exactas (=, >, <, !=) o parciales respectivamente, pero sobre una única tabla:
http://wiki.europio.org/virtualbooks/bookpage/ver/82
http://wiki.europio.org/virtualbooks/bookpage/ver/83

Esto podría llegar a yudarte "parcialmente" sin embargo, en mi opinión profesional, mientras que una herramienta no resuelva el problema completo, siempre es preferible hallar un modo propio de hacerlo.

Creo que en este caso en particular, lo que deberías crear es un módulo a modo de interfaz gráfica de acceso a datos. ¿Qué significa esto? Que indipendientemente de tus modelos, tendrías un módulo extra que simplemente manipulara las tablas haciendo consultas directas a los datos. Esto es peligroso para el diseño de la app, pero es una alternativa viable siempre que sea independiente a los modelos.

Para no tocar las tablas, como alternativa más segura pero mucho más compleja, podrías hacer que tus controladores provean de apis que retornen TODOS los datos que necesiten (casi que te permita clonar las tablas, pero de forma temporal y si es posible, en memoria -será posible dependiendo de la cantidad de datos-). Desde tu módulo, entonces, en vez de tocar las tablas, utilizarías los datos provistos por las API para obtener los mismos resultados. Y aquí, es cuestión de ponerse creativos, porque con esos datos puedes crear desde simples funciones que hagan los filtros adecuados sin usar SQL, hasta crear tablas temporales y filtrar los datos con SQL.

lo importante, creo yo, es entender que es un requerimiento enfocado en bases de datos y no en objetos.
Entendiendo eso, hay dos caminos:
- si el requerimiento es fehaciente y no es producto de un error de análisis, entonces hay que ponerse creativo para trabajar de forma externa con los datos sin arruinar el diseño de objetos.
- si hay dudas sobre la veracidad del requerimiento, volver a analizarlo y cerciorarse de que el diseño de objetos sea el adecuado.

Excelente, es evidente que el error radica en el diseño de los objetos, por ahora no cabe en mi mente como mejorarlo y por lo visto tendré que volver a leer un poco de teoría para el próximo proyecto, por ahora me veo limitado por la cantidad de registros por esto creo que por ahora la mejor opción seria implementar un modulo para la gestión de la base de datos muy cuidadosamente.
Gracias, eres la mejor. <3