Laden...

EF6 - Automatische Migration - Ungenutzte Spalten ignorieren

Erstellt von Palladin007 vor 6 Jahren Letzter Beitrag vor 6 Jahren 1.795 Views
Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren
EF6 - Automatische Migration - Ungenutzte Spalten ignorieren

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

D
985 Beiträge seit 2014
vor 6 Jahren

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.

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

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.

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

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

D
985 Beiträge seit 2014
vor 6 Jahren

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.

16.807 Beiträge seit 2008
vor 6 Jahren

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:

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.

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

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.

16.807 Beiträge seit 2008
vor 6 Jahren

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).

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

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

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