El título suena muy a "la he liado parda por favor échame una mano". En efecto. Básicamente (y creo que lo repetiré varias veces a lo largo del artículo para que queda claro), la mejor solución para no llegar nunca a este punto es hacer dumps de vuestras bases de datos.
Aunque hasta ahora es cierto que hemos creado un model (bueno, dos), una view y una template, hemos configurado el root context de la aplicación y sabemos más o menos cómo funciona y cómo movernos por ella, de momento no hemos interactuado demasiado con el ZODB, nos falta agregar datos a ese modelo Twitts que creamos en su día y, obviamente, mostrarlos.
Siguiendo con esta serie de artículos sobre Pyramid y ZODB ya hemos escrito nuestros primeros modelos, así que ya podemos interactuar con ellos de alguna forma: a través de las views.
Si hacemos memoria, hasta el momento ya sabemos montar un proyecto y un entorno mínimo de trabajo, entendemos la estructura del mismo, incluso nos hemos arriesgado a modificarla ligeramente según nuestras necesidades; y sabemos a pies juntillas cómo funciona el despachador de urls de Traversal contra la ZODB.
En capítulos anteriores hemos visto cómo montar el entorno y cómo entenderlo y adaptarlo mínimamente a nuestras necesidades organizativas. Hoy trataremos de abordar el tema del despachador de URL's... ¡qué mal suena en castellano!
En la anterior entrada hemos visto lo más básico de cómo crear un entorno y un proyecto inicial con Pyramid + ZODB, en este post vamos a intentar entender el proyecto y adaptarlo un poco a nuestra forma de trabajar, para ello nada mejor que empezar echándole un vistazo a lo que pcreate ha hecho por nosotros:
Las series de artículos no son lo mío, creo que no he llegado a completar las que he empezado, pero hay que intentarlo. Entiendo que con esa premisa serán pocos los arriesgados lectores que lleguen al final, pero es una de las excusas que tengo para ponerme al lío con este nuevo reto, así que el que avisa.
Es tal el interés por el foro de VamosaVidas (si, ese que rompí en su día y he vuelto a arreglar) que todos los días tenemos cientos de registros. Realmente se trata de robots que se dedican a hacer spam, pero eso es lo de menos :P.
¿Nunca os ha pasado aquello de que algo que conceptualmente no debería funcionar, lo pruebas más por desesperación que por otra cosa y resulta que al final no resulta ser una mala idea?
Tarde o temprano llegaría la hora de trabajar con branches. Y ello lleva inequívocamente a tener que mezclarlas algún día. Suponiendo un escenario de repositorio con dos ramas (default, new), una vez el código es estable y está probado, haremos lo siguiente: