Modification des tables de base de données dans Django

StackOverflow https://stackoverflow.com/questions/35991

  •  09-06-2019
  •  | 
  •  

Question

J'envisage d'utiliser Django pour un projet que je démarre (pour info, un jeu par navigateur) et l'une des fonctionnalités que j'aime le plus est d'utiliser syncdb pour créer automatiquement les tables de base de données basées sur les modèles Django que je définis (une fonctionnalité que je n'arrive pas à trouver dans aucun autre framework).Je pensais déjà que c'était trop beau pour être vrai quand j'ai vu ça dans le Documentation:

Syncdb ne modifiera pas les tables existantes

syncdb créera uniquement des tables pour les modèles qui n'ont pas encore été installés.Il n'émettra jamais d'instructions ALTER TABLE pour correspondre aux modifications apportées à une classe de modèle après l'installation.Les modifications apportées aux classes de modèles et aux schémas de bases de données impliquent souvent une certaine forme d'ambiguïté et, dans ces cas, Django devrait deviner les modifications correctes à apporter.Il existe un risque que des données critiques soient perdues au cours du processus.

Si vous avez apporté des modifications à un modèle et souhaitez modifier les tables de base de données pour qu'elles correspondent, utilisez la commande sql pour afficher la nouvelle structure SQL et comparez-la à votre schéma de table existant pour appliquer les modifications.

Il semble que la modification des tableaux existants devra être effectuée "à la main".

Ce que j'aimerais savoir, c'est la meilleure façon de procéder.Deux solutions me viennent à l'esprit :

  • Comme le suggère la documentation, effectuez les modifications manuellement dans la base de données ;
  • Faites une sauvegarde de la base de données, effacez-la, créez à nouveau les tables (avec syncdb, puisque maintenant il crée les tables à partir de zéro) et importez les données sauvegardées (cela peut prendre trop de temps si la base de données est grande)

Des idées?

Était-ce utile?

La solution

Comme indiqué dans d'autres réponses au même sujet, assurez-vous de regarder le Panneau d'évolution du schéma DjangoCon 2008 sur Youtube.

Egalement, deux nouveaux projets sur la carte : Migrations simples et Migratoire.

Autres conseils

Effectuer manuellement les modifications SQL et le dump/reload sont les deux options, mais vous pouvez également consulter certains des packages d'évolution de schéma pour Django.Les options les plus matures sont Django-évolution et Sud.

MODIFIER:Et hé, voici migrations.

MISE À JOUR:Puisque cette réponse a été initialement écrite, Django-évolution et migrations ont à la fois cessé leur développement actif et Sud est devenu le standard de facto pour la migration de schéma dans Django.Des parties de South pourraient même être intégrées à Django dans une ou deux prochaines versions.

MISE À JOUR:Un framework de migration de schémas basé sur South (et rédigé par Andrew Godwin, auteur de South) est inclus dans Django 1.7+.

Un bon moyen d'y parvenir est d'utiliser les appareils, en particulier le initial_data agencements.

Un appareil est une collection de fichiers contenant le contenu sérialisé de la base de données.C'est donc comme avoir une sauvegarde de la base de données, mais comme c'est quelque chose dont Django est conscient, il est plus facile à utiliser et présentera des avantages supplémentaires lorsque vous effectuerez des choses comme des tests unitaires.

Vous pouvez créer un appareil à partir des données actuellement dans votre base de données en utilisant django-admin.py dumpdata.Par défaut les données sont au format JSON, mais d'autres options telles que XML sont disponibles.Un bon endroit pour ranger les luminaires est un fixtures sous-répertoire de vos répertoires d'applications.

Vous pouvez charger un luminaire en utilisant django-admin.py loaddata mais plus important encore, si votre appareil porte un nom comme initial_data.json il sera automatiquement chargé lorsque vous effectuerez un syncdb, ce qui vous évite d'avoir à l'importer vous-même.

Un autre avantage est que lorsque vous courez manage.py test pour exécuter vos tests unitaires, la base de données de test temporaire aura également le dispositif de données initial chargé.

Bien sûr, cela fonctionnera lorsque vous ajouterez des attributs aux modèles et aux colonnes de la base de données.Si vous supprimez une colonne de la base de données, vous devrez mettre à jour votre appareil pour supprimer les données de cette colonne, ce qui pourrait ne pas être simple.

Cela fonctionne mieux lorsque vous effectuez de nombreuses petites modifications de base de données pendant le développement.Pour mettre à jour les bases de données de production, un script SQL généré manuellement peut souvent fonctionner mieux.

J'utilise Django-evolution.Les mises en garde incluent :

  • Ses suggestions automatiques ont été uniformément pourries ;et
  • Sa fonction d'empreinte digitale renvoie différentes valeurs pour la même base de données sur différentes plateformes.

Cela dit, je trouve la coutume schema_evolution.py approche pratique.Pour contourner le problème d'empreinte digitale, je suggère un code comme :

BEFORE = 'fv1:-436177719' # first fingerprint
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486'

fingerprints = [
    BEFORE, AFTER,
    BEFORE64, AFTER64,
    ]

CHANGESQL = """
    /* put your SQL code to make the changes here */
    """

evolutions = [
    ((BEFORE, AFTER), CHANGESQL),
    ((BEFORE64, AFTER64), CHANGESQL)
    ]

Si j'avais plus d'empreintes digitales et de modifications, je les refactoriserais.En attendant, le rendre plus propre reviendrait à voler du temps de développement à autre chose.

MODIFIER: Étant donné que je construis manuellement mes modifications de toute façon, je vais essayer migrations la prochaine fois.

extensions de commande Django est une bibliothèque Django qui donne des commandes supplémentaires pour manage.py.L'un d'eux est sqldiff, qui devrait vous donner le SQL nécessaire pour mettre à jour votre nouveau modèle.Il est cependant qualifié de « très expérimental ».

Jusqu'à présent, dans mon entreprise, nous avons utilisé l'approche manuelle.Ce qui vous convient le mieux dépend beaucoup de votre style de développement.

Nous n'avons généralement pas beaucoup de changements de schéma dans les systèmes de production et des déploiements quelque peu formalisés du développement vers les serveurs de production.Chaque fois que nous déployons (10 à 20 fois par an), nous effectuons une comparaison complète de la branche de production actuelle et à venir, en examinant tout le code et en notant ce qui doit être modifié sur le serveur de production.Les modifications requises peuvent être des dépendances supplémentaires, des modifications du fichier de paramètres et des modifications de la base de données.

Cela fonctionne très bien pour nous.Tout automatiser est une vision de niche mais trop difficile pour nous - peut-être pourrions-nous gérer les migrations, mais nous aurions quand même besoin de gérer une bibliothèque, un serveur supplémentaire, quelles que soient les dépendances.

Django 1.7 (actuellement en développement) est ajout du support natif pour la migration de schéma avec manage.py migrate et manage.py makemigrations (migrate obsolète syncdb).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top