web2py, DAL y las migraciones

Hace un tiempo estoy usando web2py. Web2py es un frameworks que ya viene con un montonazo de cosas para hacer páginas web. Una que estoy usando bastante es el layer de abstracción de datos (DAL), que te abstrae de la base de datos. El DAL, en teoría, se encarga de migrar la base cuando hay un cambio en el modelo de datos. Suena muy lindo, pero en la práctica tiene algunos problemillos.
¿Cómo hace para saber cómo migrar? En el directorio databases de la webapp genera unos archivos .table donde tiene guardada la estructura actual de la base y cuando evalúa los modelos los compara contra lo que tiene generado.Y cuando te conectás a la base desde un solo host, anda bien.
El problema es cuando clonás tu repo y te conectás a la base desde otro lado. ¿Qué hacer con esos archivos? Encima, el nombre de los archivos incluye como prefijo un hash del connection string. Entonces si cambiás el password deja de encontrarlos, si cambiás el nombre del host deja de cambiarlos, etc.
¿Entonces qué se puede hacer?

1. Cuando construís el DAL podés pasarle el prefijo para las tablas por parámetro en el parámetro table_hash.
2. Si no querés cambiar la base, también cuando construís el DAL, podés pasarle migrate=False.
3. Creo que fake_migrate=True genera los archivos pero no altera la base y puede servir para generar las cosas que hacen falta para migrar después.

Pero esto es una chanchada. ¿Qué es lo que me gustaría a mi que pase?

• Lo ideal es que web2py mire la estructura de la base de datos y en función de eso decida si tiene que migrar o no.
• Si eso no es posible o es muy complicado, en vez de guardar archivos en un directorio debería guardar la información que necesita para hacer las migraciones de la base de datos en una tabla de la base de datos, así la información estaría en todos lados.

Si quieren ver los detalles, miren dentro de web2py la clase DAL que está en el archivo dal.py.

Happy hacking,
Aureliano.

Mejoras en sandro

Hice varias mejoras en sandro. Ahora se puede definir módulos que son endpoints y se cargan dinámicamente, definir rutas estáticas y ¡debuggear desde eclipse! Estos features llevaron sorprendentemente poco código.

Y ¡sigue pudiéndose compartir fácilmente código entre cliente y server! Ya está tomando forma y tiene cosas que no tienen la mayoría de los frameworks para hacer páginas web.

¿Cuándo hacés tu proyecto en sandro?,
Aureliano.

Inutilizando el caching de contenido estático en tornado

Update: El setting debug=True hace que se recargue todo lo que puede ser recargado. Creo que este hack no hace falta.

Este pequeño método deja sin efecto el cache de contenido estático de tornado.

def debug_hacks():

    from tornado.web import StaticFileHandler
    import time
   
    StaticFileHandler.CACHE_MAX_AGE = 0.1 #caches 0.1 seconds

    def clean_hash_cache():
        while True:
            StaticFileHandler.reset()
            time.sleep(0.1)
           
    clean_thread = threading.Thread(target=clean_hash_cache)
    clean_thread.daemon = True
    clean_thread.start()

Hay que ejecutarlo antes de arrancar tornado para que sirva.

Happy hacking,
Aureliano.