[pyar] Cómo forzar a Django a consultar efectivamente la base de datos

[Aníbal Lovaglio]

Hola de nuevo!
acabo de encontrar la solución a mi problema y la comparto para cerrar el tema.

pasen y vean esto: http://stackoverflow.com/questions/3346124/how-do-i-force-django-to-ignore-any-caches-and-reload-data

Gracias!



________________________________
 De: Aníbal Lovaglio <aniballovaglio en yahoo.com.ar>
Para: Python Argentina <pyar en python.org.ar> 
CC: "sercom2012 en googlegroups.com" <sercom2012 en googlegroups.com> 
Enviado: domingo, 9 de diciembre de 2012 17:12
Asunto: [pyar] Cómo forzar a Django a consultar efectivamente la base de datos
 

Hola a todos!

Mi consulta de hoy es algo que me está impidiendo progresar hace ya algunas semanas. Estoy trabajando en una aplicación con Django 1.4.1 por la que ya he consultado anteriormente. Todo la información del proyecto la pueden encontrar en el readme del proyecto en http://github.com/elcoyaman/seal.

Contexto:
En pocas palabras, esta aplicación cuenta de dos módulos, supuestamente independientes para desplegarse. El primero es un módulo web con la interfaz de usuario donde los Docentes registrados en la aplicación pueden crear trabajos prácticos, y los alumnos pueden subir entregas para estos mismos trabajos prácticos. Dado que planeamos usarla para materias de programación, la idea es que la aplicación corra un script, asociado al trabajo práctico por el que se hace la entrega, para verificar lo que,
 quien corra el script, considere conveniente. Para esto, creamos una entidad 'Autocheck', que se crea en el momento que un alumno hace una entrega y queda asociada a ella, con un estado pendiente de ser revisada.

Ahora es cuando intervendría el segundo módulo. Se trata de un proceso, corriendo en background, distinto del proceso del servicio web, que cada cierto tiempo, traiga estas entidades 'Autocheck' cuyo estado sea pendiente, las procese y guarde los resultados. El caso es que, este proceso independiente que corre en background, tiene una particularidad. Si cuando se lanza este demonio, hay chequeos pendientes, los trae, los levanta como se espera, y guarda los resultados, que se reflejan inmediatamente en la interfaz web (hasta acá, sin inconvenientes). El problema viene cuando se generan nuevas entregas, y por tanto, nuevos Autochecks en estado pendiente, una vez que el demonio ya está andando. En este caso, el exacto mismo código que
 una vez trajo los datos de la base, ahora no lo hace.

Mi sospecha es que el ORM de django que usa el demonio, al ser una instancia separada del de la interfaz web, y al no haber registrado a través suyo la inserción de estos nuevos objetos en la DB, asume que no hubo cambios, y por tanto, evita ir a la base de datos para no hacer consultas "innecesarias". Mi problema es que no encontré nada parecido googleando, ni en la documentación de Django, y tengo miedo de estar encarando mal el problema. La única alternativa que veo hasta ahora, es que, en vez de tener un daemon que cada cierto tiempo haga algo, cada cierto tiempo lance un proceso separado (para que funcione como si fuera la primera vez) que haga eso mismo, y termine.


Pregunta:
¿Existe alguna manera de invocar la funcionalidad de consulta de Django, que fuerce al ORM a consultar la base de datos a pesar de no haber registrado cambios? Es decir ¿hay alguna configuración, argumento del método filter, o lo que sea, que fuerce la consulta real a la DB?
Lo que estoy buscando concretamente es algo como:

pending_autochecks = Autocheck.objects.filter(status='pending', flush=True)

o algún valor en settings.py como:

USE_CACHE = False

Desde ya muchas gracias.
Aníbal

_______________________________________________
pyar mailing list pyar en python.org.ar
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20121209/e0a8fba0/attachment.html>