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
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
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.
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.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
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
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
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.
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
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).
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.