Le flux de travail Django lors de la modification fréquente de modèles?

Question

comme je ne fais généralement pas la conception initiale de mes modèles dans les projets Django, je modifie beaucoup les modèles et supprime donc ma base de tests à chaque fois (car & "; syncdb &"; gagné jamais modifier les tables automatiquement pour vous). Ci-dessous se trouve mon flux de travail et j'aimerais entendre parler du vôtre. Toutes les pensées sont les bienvenues ..

1. Modifiez le modèle.
2. Supprimez la base de données de test. (toujours une base de données sqlite simple pour moi.)
3. Exécuter " syncdb ".
4. Générez des données de test via le code.
5. goto 1.

Une question secondaire à ce sujet. Si votre flux de travail est comme ci-dessus, comment exécutez-vous l'étape 4.? Générez-vous les données de test manuellement ou existe-t-il un point de raccordement adéquat dans les applications Django où vous pouvez injecter le code de génération de données de test au démarrage du serveur? \

TIA.

Answer 1

Étapes 2 & amp; 3 peut être fait en une étape:

manage.py reset appname

À ma connaissance, l'étape 4 est plus facile à gérer en utilisant fixtures

Answer 2

Ceci est un travail pour les fixtures de Django. Ils sont pratiques car ils sont indépendants de la base de données et que le test harnais (et manage.py) les prend en charge.

Pour les utiliser:

1. Configurez vos données dans votre application (appelez il & "; foo &";) en utilisant l'outil d'administration
2. Créez un répertoire de fixtures dans votre " toto " répertoire app
3. Type: python manage.py dumpdata --indent=4 foo > foo/fixtures/foo.json

Maintenant, après votre étape syncdb, il vous suffit de taper:

 python manage.py loaddata foo.json

Et vos données seront recréées.

Si vous les souhaitez dans un scénario de test:

class FooTests(TestCase):
    fixtures = ['foo.json']

Notez que vous devrez recréer ou mettre à jour manuellement vos appareils si votre schéma change radicalement.

Vous pouvez en savoir plus sur les fixtures dans les django docs pour Chargement des fixtures

Answer 3

Voici ce que nous faisons.

1. Les applications portent un numéro de version de schéma. appa_2, appb_1, etc.

2. Les modifications mineures ne changent pas le nombre.

3. Les modifications majeures incrémentent le nombre. Syncdb fonctionne. Et une & Quot; migration de données & Quot; le script peut être écrit.

   def migrate_appa_2_to_3():
       for a in appa_2.SomeThing.objects.all():
           appa_3.AnotherThing.create( a.this, a.that )
           appa_3.NewThing.create( a.another, a.yetAnother )
       for b in ...
   

Le fait est que supprimer et recréer ne sont pas toujours appropriés. Il est parfois utile de déplacer les données de l'ancien modèle dans le nouveau modèle sans reconstruire à partir de zéro.

Answer 4

Le sud est le plus cool.

Bien que le bon vieux reset fonctionne mieux quand les données n’ont pas d’importance.

http://south.aeracode.org/

Answer 5

Pour ajouter à la réponse de Matthew, j'utilise souvent aussi le code SQL personnalisé pour fournir les données initiales décrites dans la documentation ici .

Django ne fait que rechercher des fichiers dans <app>/sql/<modelname>.sql et les exécute après la création de tables au cours de syncdb ou sqlreset. J'utilise du SQL personnalisé lorsque je dois faire quelque chose comme peupler mes tables Django à partir d'autres tables de base de données non Django.

Answer 6

Personnellement, ma base de développement est destinée à un projet sur lequel je travaille actuellement, elle est plutôt volumineuse. Je me sers donc de dmigrations pour créer des scripts de migration de la base de données afin de modifier la base de données (plutôt que de l'effacer à chaque fois comme je le faisais au début).

Modifier: En fait, j'utilise Sud maintenant: -)