[erledigt] EF5 Code First Migrations: Datenhaltung bei Update des Schemas

verwendetes Datenbanksystem: SQL 2008 + EF5

Hallo zusammen,

ich befinde mich aktuell bei einem Refactoring meiner Anwendung. Aufgrund von neuen spezifikationen und gewünschter Features ist auch eine Änderung des Datenbank-Schemas von Nöten.
Das heißt, dass Relationen geändert werden, Properties verschoben werden und neue Entities hinzu kommen werden.

Bisher habe ich immer mit EF 4, EDMX Designer und dem POCO DbContext Generator gearbeitet. Sprich an für sich war das, was am Ende raus kommt identisch mit der Code First Variante.
Ich möchte jetzt aber weitere Features nutzen, die auf das komplette Verzichten des EDMX Designers drängen.

Gibt es im EF4.3.1 / EF5 einen Best-Practise-Weg, um bei einer Datenbank-Migration die existierenden Daten beizubehalten? Eventuell schon auf automatischem Weg? Schließlich sind Automatic-Migrations im EF5 jedenfalls stichwortartig angedeutet.

Die Initial-Migration habe ich bereits durchgeführt, doch die leider nur sehr sehr spärliche und teilweise veraltete Dokumentation vom EF macht es alles andere als leicht, wie ich in solch einem Fall am besten vorgehen soll. Gibt zwar einige Ansätze vonwegen Initial-Inserts oder Up/Down-Migration aber das ist nicht das, was ich unter Automatic Migrations verstehe.

Vielleicht hat der ein oder andere von Euch schon positive / negative Erfahrungen und schon die ersten Tücken und Macken entdeckt.

Danke für Tipps.

Grüße vom Abt

Hi Abt,
vor dem selben problem stand ich erst letzten Monat :
Eine Anwendung auf EF 4.1 Code First hieven und Daten übernehmen aber properties teiweilse ändern.

Ich habe keine Best Practise Lösung bin aber wie folgt vorgegangen : Per EF Code First die Alte Datenstruktur abgebildet und die neue erstellt.
Dann habe ich einen Mapper geschrieben, welcher mir von alt auf neu mappt.

Dann ging es los : beim Initialisieren des DB Context wird gepürft ob die Version der DB aktuell ist. Wenn nicht spult sich folgendes programm ab:

Holle alle Altdaten -> erstelle die neue DB Struktur -> Mappe Alt auf neu -> Schreibe in DB

Nicht der schönste Weg aber immer einer 😄

Grüße

Hallo,

danke für Deine Antwort.
Hast Du hierfür die Schnittstellen von DbContext verwendet, oder quasi eine Update-Applikation geschrieben?

Das Problem ist ja mit unter auch, dass die Variante des EDMX Generators nicht all die Properties benötigt, wie sie zum Beispiel ein Code First hat. So wird beim EDMX Designer aufgrund des Mappings bei 1-n eine Zusatzspalte in der Datenbank genutzt; das Mapping findet hier in den Metadaten statt - nicht im Code.

Bei Code First hab ich hierfür direkt eine Property.

Ich fürchte wirklich sauber bekomm ich eine Migration (fast) nicht hin, ohne, dass die Daten alle ausgelagert werden müssen.

Hi,

den DatenbankContext habe ich in dem sinne nur erweitert, dass ich ne kleine UpdaterAnwendung implementiere. Dieses ist aber "extern" und wird über das Setup aufgerufen. (App startet prüft Version und bei "alter" Version der DB wird der Updater aufgerufen. )
Ich denke, bei einer so komplexen Migration, welche du anscheinend auch hast, wirst du um eine Art "manuelles tranferprogramm" nicht drum rum kommen.

Aber : Ein Updater ist ja auch nicht die schlechteste Lösung 😉

Grüße

Der DbContext stellt ja auch Up / Down Methoden zur Verfügung. Ebenso Schnittstellen, die greifen, wenn sich das Model geändert hat.

Das Problem das ich nur sehe: ich kann an dieser Stelle überhaupt keine Datensicherung vornehmen!
Denn: Ich änder das Model im Source -> altes Schema passt nicht mehr, daher kann ich die Daten von der DB mit dem alten Schema nicht via ORM raus ziehen.

Ergo:
Schritt 1: altes Modell-Schema nutzen um die Daten zu ziehen
Schritt 2: neues Schema implementieren
Schritt 3: Daten von alten Modell ins neue Übertragen
Schritt 4: Daten in der DB committen

Wie gesagt - ich versteh unter "automatic / auotmated migrations" einfach irgendwie was anderes 🤔
Jedoch bin ich nun auch über einige Blogs gestolpert, die sagen, dass automatic migrations viel mit Ghost-Scripts arbeiten; sprich es kaum nachvollzogen werden kann, was wirklich passiert.

Riecht irgendwie so, als sei das alles nur integriert worden, damit die Community ein wenig ruhiger ist. Doch durchdacht wirkt das alles nicht so wirklich.

Ja, der Context bietet da eine Menge wenn sich zB im Ursprünglichen Model was ändert. Ich sehe dieses ganzen Features aber etwa so : Ja wir haben was um kleine Änderungen zu kompensieren, komplexe Sachen bitte zu Fuß.

Ich denke, der weg den du beschreiten willst mit deinen 4 Schritten wird die einzige Lösung sein... wir können nur hoffen, das MS mit EF 6 weiter sein wird 😉

Ich denke aber auch, dass es einen Unterschied macht, ob nun innerhalb des EF eine Migration erwartet wird, oder, ob ich ein bereits bestehendes Schema migrieren will.

Dass ein automatischer Migrationsprozess nicht funktionieren kann, wenn ich keine Quellinformationen hab - das ist ja klar.
Aber ich will ja eigentlich nur ein bestehendes Schema erweitern - hier sollte das in meinen Augen also funktionieren. Wieso er aber einfach die Daten verwirft und dann dennoch von einer automatischen Migration gesprochen wird erschließt sich mir nicht.

Ich vermute ich überseh irgendwas, was vielleicht ein anderer gesehen hat.
Gibt es denn keinen implementierten Weg, um in EF4.3.1/EF5 eine Migration in einem Durchgang flüssig umzusetzen? Das würde mich nun von dem Prinzip her echt schwer enttäuschen.

Was natürlich auch möglich wäre:
EF 4.3 Automatic Migrations Walkthrough

Im Up einfach neue Spalten anfügen zB

Aber dafür MUSS ein Model bereits exisitiert haben, ansonsten bleibt wohl nur die zu Fuß Methode

Danke fürs Raussuchen; aber das kenn ich bereits ganz gut 😉

Geht ja auch nicht nur darum, dass ich neue Spalten hab.
Teilweise lager ich eben auch Spalten in neues Entities ab - diese Logik nimmt der Migrationsprozess hier aber nicht auf (er weiß ja bei der Model-Definition gar nicht, dass ich nur eine Property verschiebe).

Schade. Schade. Bleibt wohl wirklich nur der Fußweg über eine externe Implementierung. Genau das wollt ich gerade auch aus Zeitgründen vermeiden 😦

Jop so habe ich es auch gemacht: per exterenm Prozess .... bleibt dir wohl keine andere Wahl 😦

Update von meiner Seite aus: Es funktioniert doch.

Hintergrund:
Mein Projekt ist folgendermaßen aufgebaut

ProjectName.MVCApplication
ProjectName.Business.XYZ
++ProjectName.Database.Models ++
ProjectName.Database.XYZ

Ich bin eigentlich davon ausgegangen, dass ich die Migration auf der Anwendungsseite erstelle, sodass die Anwendung entscheidet, welche Datenbankversion für die derzeit die richtige ist.
Die Macher des EF sehen das anscheinend ein wenig anders.

Wenn ich das TargetProject für die Migration Commands über die PowershellConsole von meiner MVCApplication auf das Projekt ProjectName.Database.Models, in dem meine Entities und das Mapping etc liegt, ändere, dann funktioniert auch ein Update / Downgrade des Schemas inklusive der Datenhaltung.

Perfekt 😃