myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
   » Plugin für Firefox
   » Plugin für IE
   » Gadget für Windows
» Regeln
» Wie poste ich richtig?
» Datenschutzerklärung
» wbb-FAQ

Mitglieder
» Liste / Suche
» Stadt / Anleitung dazu
» Wer ist wo online?

Angebote
» ASP.NET Webspace
» Bücher
» Zeitschriften
   » dot.net magazin

Ressourcen
» guide to C#
» openbook: Visual C#
» openbook: OO
» MSDN Webcasts
» Search.Net

Team
» Kontakt
» Übersicht
» Wir über uns
» Impressum

» Unsere MiniCity
MiniCity
» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Datentechnologien » EF6 - Automatische Migration - Ungenutzte Spalten ignorieren
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

EF6 - Automatische Migration - Ungenutzte Spalten ignorieren

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Palladin007
myCSharp.de-Mitglied

Dabei seit: 03.02.2012
Beiträge: 924
Entwicklungsumgebung: Visual Studio 2010 Express


Palladin007 ist online

EF6 - Automatische Migration - Ungenutzte Spalten ignorieren

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

verwendetes Datenbanksystem: TSQL, EF6

Guten Vormittag,

ich hab eine kleine Datenbank, auf die ich mit EF6 zugreife.
Eine manuelle Migratioin bei Änderungen würde ich gerne vermeiden, bisher hat die automatische Migration vollkommen ausgereicht.

Allerdings scheint die automatische EF6-Migration auch Spalten entfernen zu wollen, die es nicht kennt.
NHibernate verhält sich da anders, das löscht keine Spalten oder Tabellen, es versucht sie beim Update nur zu erstellen, wenn sie fehlen.

Genau dieses Verhalten will ich bei EF6 auch haben.
Aktuell ist es aber so, dass ich immer einen Fehler bekomme, wenn er versucht zu migrieren, da ich den Datenverlust nicht erlaube.
Ich müsste also AutomaticMigrationDataLossAllowed auf true setzen, damit die automatische Migration funktioniert und genau das will ich nicht.

Hat jemand eine Idee, wie ich das erreichen kann?

Beste Grüße
19.05.2017 10:50 Beiträge des Benutzers | zu Buddylist hinzufügen
Sir Rufo Sir Rufo ist männlich
myCSharp.de-Mitglied

images/avatars/avatar-3523.jpeg


Dabei seit: 06.07.2014
Beiträge: 811
Entwicklungsumgebung: VS2017
Herkunft: Stadthagen


Sir Rufo ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Du bekommst doch für jede Migration eine Klasse wo in den Up Down Methoden beschrieben wird, was an den Tabellen geändert werden soll.

Es sollte reichen die Zeilen zu entfernen die das Entfernen (Up) / Hinzufügen (Down) der Spalten veranlassen.
19.05.2017 10:54 Beiträge des Benutzers | zu Buddylist hinzufügen
Palladin007
myCSharp.de-Mitglied

Dabei seit: 03.02.2012
Beiträge: 924
Entwicklungsumgebung: Visual Studio 2010 Express

Themenstarter Thema begonnen von Palladin007

Palladin007 ist online

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Ich rede von der automatischen Migration, ich möchte die weiter verwenden.
Da habe ich keine entsprechenden Klassen, ich habe nur eine DbMigrationsConfiguration-Ableitung, wo AutomaticMigrationsEnabled auf true gesetzt wird.
19.05.2017 10:56 Beiträge des Benutzers | zu Buddylist hinzufügen
Palladin007
myCSharp.de-Mitglied

Dabei seit: 03.02.2012
Beiträge: 924
Entwicklungsumgebung: Visual Studio 2010 Express

Themenstarter Thema begonnen von Palladin007

Palladin007 ist online

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Wenn ich die POCO-Klassen mit dem Datenmodell vergleiche, finde ich auch keinen Unterschied, der zu einem Datenverlusst führen würde.

Ich habe nur Spalten hinzugefügt, keine entfernt.
Auch sowas wie Keys oder Constraints habe ich nicht geändert - nur eine weitere String-Property

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Palladin007 am 19.05.2017 11:43.

19.05.2017 11:42 Beiträge des Benutzers | zu Buddylist hinzufügen
Sir Rufo Sir Rufo ist männlich
myCSharp.de-Mitglied

images/avatars/avatar-3523.jpeg


Dabei seit: 06.07.2014
Beiträge: 811
Entwicklungsumgebung: VS2017
Herkunft: Stadthagen


Sir Rufo ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Führe diese Änderungen doch mal (in einem separaten Projekt) per Add-Migration aus, dann siehst du wenigstens was er da wie ändern will.

Die Meldung kommt auch, wenn man die Länge eines Felds ändert (verkleinert). Das fällt manchmal aber gar nicht so schnell auf. Evtl. musst du dir das aktuelle Schema anschauen und dann mit deiner Klassendefinition vergleichen.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Sir Rufo am 19.05.2017 12:25.

19.05.2017 12:25 Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

images/avatars/avatar-2981.png


Dabei seit: 20.07.2008
Beiträge: 10.450
Herkunft: Süddeutschland


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Es wird eigentlich empfohlen AutomaticMigrationsEnabled nicht zu nutzen.

Das Problem ist, dass AutomaticMigrationsEnabled keine strikte Versionierung ermöglich und man daher auch keine Versionierung der Datenbank durchführen kann.

Zusätzlich der Hinweis:

Zitat:
Recommendation for Team Environments

You can intersperse automatic and code-based migrations but this is not recommended in team development scenarios. If you are part of a team of developers that use source control you should either use purely automatic migrations or purely code-based migrations. Given the limitations of automatic migrations we recommend using code-based migrations in team environments.
19.05.2017 12:29 Beiträge des Benutzers | zu Buddylist hinzufügen
Palladin007
myCSharp.de-Mitglied

Dabei seit: 03.02.2012
Beiträge: 924
Entwicklungsumgebung: Visual Studio 2010 Express

Themenstarter Thema begonnen von Palladin007

Palladin007 ist online

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Das aktuelle Schema aus der Migrations-Tabelle könnte ich mal raus ziehen und vergleichen, ja - mach ich, sobald ich Zeit habe
Wenn ich aber das DB-Schema direkt mit den Klassen vergleiche, gibt's keinen Unterschied. Natürlich habe ich auch sowas wie String-Längen verglichen.

Mir ist auch klar, dass die automatische Migration Nachteile hat und dass es für Teamentwicklung nicht empfohlen ist.
Aber das Projekt ist sehr klein und überschaubar, auch ist die einzige Datenbank sehr klein. Das Projekt wird intern verwendet, wir haben Vollzugriff auf die Datenbank und wenn überhaupt gibt's nur nur noch wenige Änderungen.
Dafür eine Code-basierte Migration zu bauen, lohnt einfach nicht.

Das Problem ist aber, dass die automatische Migration ständig versucht, irgendetwas zu migrieren, was angeblich einen Datenverlust bedeutet.
EF6 soll mir Tabellen und Spalten erstellen, alle Änderungen, die zu Datenverlust führen würden, sollen einfach ignoriert werden.

Wenn das nicht geht, wird's wohl darauf hinaus laufen, dass wir die Migration komplett per Hand machen. Auf die Zeit gerechnet ist das sehr viel effektiver.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Palladin007 am 19.05.2017 14:09.

19.05.2017 14:06 Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

images/avatars/avatar-2981.png


Dabei seit: 20.07.2008
Beiträge: 10.450
Herkunft: Süddeutschland


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat:
Dafür eine Code-basierte Migration zu bauen, lohnt einfach nicht.

Automatic deaktivieren und "Add-Migration <Name>" verwenden ist kein Aufwand.

Und im Deployment einfach die migrate.exe mit Connectionstring aurufen: fertig.
Das sind zwei minimale, manuelle Schritte, die einen Haufen Ärger vermeiden. Keine Notwendigkeit gleich alles von Hand zu programmieren.

Prinzipiell bin ich eher ein Fan von FluentMigrator - funktioniert einfach viel besser und kontrollierter; aber das wäre eher mehr Aufwand (in diesem Situationsvergleich).
19.05.2017 14:15 Beiträge des Benutzers | zu Buddylist hinzufügen
Palladin007
myCSharp.de-Mitglied

Dabei seit: 03.02.2012
Beiträge: 924
Entwicklungsumgebung: Visual Studio 2010 Express

Themenstarter Thema begonnen von Palladin007

Palladin007 ist online

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Oh ... :D
Den Befehl kannte ich nicht, ich dachte, ich muss das immer selber machen
Gut, das ändert natürlich einiges :D

Aber mich wundert schon, dass da tatsächlich ein DropColumn in der Up-Methode drin steht.
Scheinbar ist uns hier ein Fehler unterlaufen und die Spalte gibt's im DB-Schema nicht, aber in dem Schema, was EF6 selber dort ablegt...

Aber jetzt hab ich einen Anhaltspunkt

Danke für die Hilfe
19.05.2017 14:44 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 4 Monate.
Der letzte Beitrag ist älter als 4 Monate.
Antwort erstellen


© Copyright 2003-2017 myCSharp.de-Team. Alle Rechte vorbehalten. 17.10.2017 19:03