PostGIS, RDS y web2py

En RDS hay soporte para postGIS. El setup normal para una base de datos está documentado y es bastante complicado. A eso se suma que el DAL de web2py es bastante molesto a la hora de hacer operaciones en SQL que setupean la base, necesitando que todas las operaciones de setup sean idempotentes. El ejemplo que dan en la documentación es cómo crear índices.
Uniendo todo esto, hice un módulo de python que puse en la carpeta models de mi aplicación y ahí ejecuto lo que dice en la documentación de AWS, modificado para que sea idempotente.
Acá les regalo mi scriptcito (que nombré postgis.py).

for extension in "postgis fuzzystrmatch postgis_tiger_geocoder postgis_topology".split():
    db.executesql("CREATE EXTENSION IF NOT EXISTS %s ;" % extension)

# Change ownership, required for RDS   
if settings.rds:
    for schema in "tiger topology".split():
        db.executesql("alter schema %s owner to rds_superuser;" % schema)

    db.executesql("CREATE OR REPLACE FUNCTION setup_postgis_exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;")
    db.executesql("""\
SELECT setup_postgis_exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO rds_superuser')
  FROM (
    SELECT nspname, relname
    FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
    WHERE nspname in ('tiger','topology') AND
    relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
""")

Éxitos,
Aureliano.

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.