Mise à jour de schéma de base de données sur le changement du modèle de données sans perte de données

Fond: disons que je suis en utilisant entity framework et de l'une des entités mappées est donnée sous la forme:

class Foo
{
    public int ID { get; set; }
    public string Bar { get; set; }
    //other useful properties
}

Avec la cartographie:

class FooMap : EntityTypeConfiguration<Foo>
{
    //bear me with, I know this is redundant right now
    ToTable("Foo");
    HasKey(e => e.ID);
    Property(e => e.ID).HasColumnName("ID");
    Property(e => e.Bar);
}

Quelque part sur la route nous avons besoin de changer le nom de la colonne de Foo parce que mon patron me dit le Foo besoin d'avoir un plus extravagant que le nom ID ou l'autre de nos clients ne seront pas contents. Il nous dit de le renommer trop "FooID":

class FooMap : EntityTypeConfiguration<Foo>
{
    //bear me with, I know this is redundant right now
    ToTable("Foo");
    HasKey(e => e.ID);
    Property(e => e.ID).HasColumnName("FooID"); //Now you map to FooID
    Property(e => e.Bar);
}

Comme il est, si je lance ce rien n'aura changé. Le Foo table y aura toujours une colonne nommée ID et il va lever une exception en me disant que la colonne FooID n'existe pas.

La Question: Comment puis-je obtenir de l'entité cadre de reconnaître que je souhaite maintenant mettre à jour le Foo table, de sorte que la colonne nommée ID est maintenant nommé FooID?

Plus généralement, comment puis-je obtenir de l'entity framework pour propager automatiquement les modifications de mon code dans la base de données (par exemple au démarrage de l'application) SANS détruire les données existantes?

Je ne peux pas juste "supprimer et de recréer" la base de données parce que, pour des raisons au-delà de la portée de cette question, la base de données stocke les données d'autres dans ce qui n'est pas créé par l'intermédiaire de modèles mappé dans mon code. En le déposant serait de nous faire perdre de tables que nous ne pouvons pas recréer à l'aide de ce mécanisme.

OriginalL'auteur Mike Bailey | 2012-02-22

c#database-update ef-code-first entity-framework

4

Je crois à la suite de deux postes seront vous aider.
- À l'aide de EF 4.3 le Premier Code Migrations avec une Base de données Existante
- EF 4.3 Migration de Procédure pas à pas
Merci. Deux-commande met à jour fonctionne très bien.

OriginalL'auteur Ray
2

Comment faire pour récupérer à partir d'Entity Framework cauchemar de la base de données a déjà des tables avec le même nom

Description: Si vous êtes comme nous, lorsque votre équipe est de nouveau à EF, vous vous retrouverez dans un état où vous ne pouvez pas créer une nouvelle base de données locale ou vous ne pouvez pas appliquer les mises à jour de votre base de données de production. Vous voulez revenir à l'EF de l'environnement et puis de s'y tenir à l'essentiel, mais vous ne pouvez pas. Si vous l'obtenez de travail de la production, vous ne pouvez pas créer une bd locale, et si vous l'obtenez de travail local, votre serveur de production devient hors de synchronisation. Et enfin, vous ne voulez pas supprimer toute la production de données du serveur.

Symptôme: ne Peut pas exécuter mise à Jour de la Base de données parce que c'est en essayant de lancer le script de création et de la base de données a déjà des tables avec le même nom.

Message D'Erreur: System.Les données.SqlClient.SqlException (0x80131904):
est déjà un objet nommé " dans la base de données.

Problème de Fond: EF comprend où la base de données actuelle est par rapport à l'endroit où le code est basé sur une table dans la base de données appelée dbo.__MigrationHistory. Quand il regarde les Scripts de Migration, il essaie de reconsile où il a été le dernier à avec les scripts. S'il le peut, il essaie juste de les appliquer dans l'ordre. Cela signifie, il remonte à la création initiale de script et si vous regardez la première partie de la commande, ça va être la CreeateTable pour la table que l'erreur qui se passait sur la.

Pour comprendre plus en détail, je vous recommande de regarder les deux vidéos référencées ici:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs. 113).aspx

Solution: Ce que nous devons faire est de tromper EF en pensant que la base de données actuelle est à jour, tout en n'appliquant pas ces CreateTable commandes. Dans le même temps, nous voulons toujours ces commandes existent afin que nous puissions créer de nouvelles bases de données locales.

Étape 1: base de données de Production propre
Tout d'abord, faire une sauvegarde de votre base de données de production. Dans SSMS, Cliquez-Droit sur la base de données, Sélectionnez "Tâches" > Exporter des Données de la couche application..." et suivez les invites.
Ouvrez votre base de données de production et de supprimer/déplacer la dbo.__MigrationHistory table.

Étape 2: environnement Local propre
Ouvrez votre migrations dossier et de le supprimer. Je suis en supposant que vous pouvez obtenir tout cela en arrière à partir de git si nécessaire.

Étape 3: Recréer Initiale
Dans le Gestionnaire de paquets, exécutez "Activer les Migrations" (EF vous invite à utiliser -ContextTypeName si vous avez de multiples contextes).
Exécutez "Ajout de la Migration Initiale -verbose". Cela va Créer le script initial pour créer la base de données à partir de zéro basé sur le code actuel.
Si vous aviez des semences opérations dans la Configuration précédente.cs, puis copiez que, dans l'ensemble.

Étape 4: Astuce EF
À ce point, si nous avons couru mise à Jour de la Base de données, nous aimerions obtenir l'erreur d'origine. Donc, nous avons besoin de tromper EF à penser qu'il est jusqu'à ce jour, sans que l'exécution de ces commandes. Donc, aller dans la méthode de la migration Initiale que vous venez de créer et commenter tous.

Étape 5: Mise À Jour De La Base De Données
Avec pas de code à exécuter sur le processus, EF créer la dbo.__MigrationHistory table avec l'entrée correcte de dire qu'il a couru ce script correctement. Aller et de vérifier si vous le souhaitez.
Maintenant, décommentez que le code et les enregistrer.
Vous pouvez exécuter mise à Jour de la Base de données de nouveau si vous voulez vérifier que EF pense de son jusqu'à ce jour. Il ne sera pas exécuter l'étape avec tous les CreateTable commandes, car il pense que c'est déjà fait.

Étape 6: Confirmer EF est en FAIT jusqu'à ce jour
Si vous avez eu un code qui n'avait pas encore eu les migrations sont appliquées, c'est ce que j'ai fait...

Exécutez "Ajout De La Migration MissingMigrations"
Cela va créer pratiquement vide script. Parce que le code est déjà là, il y avait effectivement le bon de commandes pour créer ces tables dans le premier script de migration, de sorte que je viens de couper le CreateTable et l'équivalent de déposer les commandes dans le Haut et le Bas des méthodes.

Maintenant, exécutez mise à Jour de la Base de données de nouveau et de le regarder à l'exécution de votre nouveau script de migration, de créer les tableaux correspondants dans la base de données.

Étape 7: Re-confirmer et valider.
De créer, de tester, de s'exécuter. S'assurer que tout est en cours d'exécution, puis valider les modifications.

Étape 8: Laisser le reste de votre équipe, de savoir comment procéder.
Lorsque la personne à côté de mises à jour, EF ne sais pas ce qu'il frappe étant donné que les scripts, c'était exécutée avant n'existent pas. Mais, en supposant que les bases de données locales peuvent être emportés et re-créé, c'est tout bon. Ils devront déposer leur base de données locale et ajouter le créer à partir de EF à nouveau. Si ils avaient des changements locaux et dans l'attente de migrations, je vous recommande de créer leur DB à nouveau sur le master, passer à leur branche de fonctionnalité et de re-créer les scripts de migration à partir de zéro.

OriginalL'auteur System.Exception
1

vous devez utiliser Entity Framework Migrations pour ce faire

utilisez ce lien

OriginalL'auteur Jayanga

Vous devez vous connecter pour publier un commentaire.