Articles
Receptes de South
Escrit per Aaloy a 27 de May , 2012 a les 11:58 p.m.
Pels aquelles que encara no el coneixeu, permeteu-me que us presenti south una eina per a controlar els canvis que es van fent al model i poder-los aplicar a la nostra base de dades.
South és una eina fantàstica, però no substitueix ni la necessitat de fer còpies de seguretat abans de fer algun canvi que pugui significar la destrucció o alteració de dades, ni la necessària coordinació entre els diferents membres de l'equip de desenvolupament.
Al tutorial des south està molt bén explicat tot, així que aquest apunt miraré de posar les receptes que he trobat més interessants, bàsicament per a no oblidar-me'n.
Canvi de nom d'un camp
South intentarà esborrar el camp i crear-ne un de nou. No sap que el que volíeu era un canvi de nom així que:
- Fem la migració de la manera habitual
python manage.py schemamigration app --auto -
South generarà una nova migració. Amb el vostre editor preferit, editau-la i eleminau les referències a l'eliminació i creació del camp. En el seu lloc, utilitzau directament l'API de South, per escriure
db.rename_column(table_name, column_name, new_column_name)
amb les columnes en sentit contrari per desfer la migració, obviament...
Hem modificat un camp a la BD directament
Les primeres vegades que es fa servir South costa que tot l'equip s'hi acostumi. Si la gent estava acostuamada a passar scripts sql, potser els ha passat i no ha fet ús de la migració.
South detectarà que la migració no està passada i intentarà passar-la, però com que els canvis ja hi són (la taula que es vol crear ja existeix, o el camp, ...), South donarà un error i intentarà tirar la migració enrera. En el cas de Postgres no hi haurà problemes, però amb bases de dades com el MySQL que no suporten la transaccionalitat d'esquemes donarà error.
No passa res si detectau que és això el que ha passat. Però hem de dir-li a South que consideri que la migració ja està feta. Per axixò farem:
python manage.py migrate app --fake
suposant que és la darrera migracío, o bé especificant quina migració s'ha de considerar aplicacada.
python mangae.py migrate app num_migració --fake
Ja tenim la base de dades i volem començar a fer feina amb South
Per a convertir una aplicació de la qual ja teniu la base de dades creada hem de fer
python manage.py convert_to_south app
això posarà l'aplicació sota el control de south, crearà la migració inicial i la marcarà com a aplicada.
Enllaços citats
Traducciones/Translations by apertium
7 comentaris, 0 trackbacks (URL) , Tags: Python Django APSL
Comentaris
1 Comentari de Jim a les 09:05 del Monday 28 May de 2012
No habla ingles.
Why do people insist on syndicating their foreign language posts on an english centered planet? Please explain that to me because I do not get it, I really don't.
2 Comentari de aaloy a les 10:05 del Monday 28 May de 2012
Dear Jim,
Do you know what a planet is? Or for you our planet is just for english speaking people.
Django Planet has pots in many languages, is not a English centric, just Django centric.
Your limitations, sorry!
3 Comentari de oscar g a les 04:05 del Monday 28 May de 2012
@aaloy
Pues yo te agradezco que escribas en catalán.
Una pregunta, para los formularios usas algún tipo de app?
He visto que hay 2 que tienen muy buena pinta:
https://github.com/maraujop/django-crispy-forms
https://github.com/brutasse/django-floppyforms
Usas alguna de las anteriores?
Tb veo que últimamente se ha puesto de moda en la comunidad usar bootstrap
http://twitter.github.com/bootstrap/
Tu lo usas? que te parece?
Gracias por tus posts ! son realmente útiles.
4 Comentari de aaloy a les 04:05 del Monday 28 May de 2012
Crispy y floppy son complementarios. Usa los dos :) Las utilizamos y son proyectos fantásticos. Miguel Araujo, quien está detrás del proeycto crispy-forms ha hecho un trabajo fantástico. Realmente ahorran mucho trabajo.
Se supone que parte de este trabajo o idea se integrará en las próximas versiones de Django, pero mientras estos proyectos realizan muy bien su función. El tiempo invertido en aprender cómo va ya verás como lo recuperas con creces.
Bootstrap. Si utilizas crispy-forms el layout y clases por defecto es el de bootstrap, antes utilizaban uniform. Nosotros estamos utilizando bootstrap cuando el proyecto no tiene un componente de diseño gráfico imporante y podemos adaptarnos al grid de bootstrap, en caso contrario lo hacemos a mano. Es decir, utilizamos bootstrap si podemos adaptarnos y no pelearnos con el framework.
Si no utilizas bootstrap crispy-forms sigue siendo válido, ya que se pueden sobreescribir los layouts de generación del formulario y poner tus propias clases u otro diesño que utilices.
Y muchas gracias por el apoyoo moral! :D
5 Comentari de oscarg a les 06:05 del Monday 28 May de 2012
"Y muchas gracias por el apoyoo moral! :D"
De nada ! con la 'poca' gente que escribe tutoriales en castellano/catalán ya solo falta que te trolleen los americanos.
P.D.: Si te apetece hacer un mini-tutorial de floppyforms y crispy-forms pues no te diré que no ;)
6 Comentari de SebaSj a les 10:05 del Monday 28 May de 2012
Algun truco con South cuando cambiamos de nombre una tabla? :P
Gra6!
7 Comentari de aaloy a les 11:05 del Monday 28 May de 2012
Usa el api Sebasj :)
db.rename_table(table_name, new_table_name)