Aufgrund der Anwesenheit von type providers für den Zugriff auf SQL-Daten in F #, gibt es nicht viel Fokus auf die Verwendung von ORMs, Mikro oder anders. Ich kann definitiv die Logik dahinter sehen.Verwalten von SQL-Schema in F #
Es scheint auch, dass viele Beispiele für die Verwendung von F # zum Spielen mit relationalen Daten darin besteht, sie in bestehende große Datenbanken zu stecken, die anderswo zu erstellen scheinen.
Es fühlt sich an, als gäbe es hier eine kleine Lücke: Gibt es eine nette Möglichkeit, Schema-Erstellung und -Migration direkt aus F # zu verwalten? Das oben verlinkte Beispiel schlägt vor, das Skript zum manuellen Erstellen von Schemas als ersten Schritt auszuführen. Ist das die einzige Option?
Ich habe vor kurzem ein kleines Projekt angefangen, das von Anfang an F # ist, und ich versuche, einige Daten in einer relationalen Datenbank (sqlite für jetzt) zu speichern. Ich habe kein existierendes Schema zu erforschen, ich entwerfe von Grund auf neu. Gibt es eine freundlichere oder idiomatischere Art, mein Schema (Erstellung und dann Migration) in F # zu verwalten?
Ich dachte nicht einmal so weit voraus wie Migration, gerade jetzt bin ich nur neugierig auf die Erstellung von Datenbankobjekten. Ich hatte einen ähnlichen Weg eingeschlagen, wie Sie vorschlagen, obwohl in meinem Fall ServiceStack.Ormlite versucht hatte. Für den Dialekt-Support allein scheint es eine lohnende "überflüssige" Investition zu sein. –
Entschuldigung - wenn ich "Migration" sagte, bezog ich mich auf die Fähigkeit von EF, ein SQL-Schema basierend auf einer Reihe von OO-Beziehungen zu generieren. –
Oh meinst du 'migrieren Klassenstruktur zu einer Schemadefinition', nicht 'migrieren Datenbankschema Version 1 zu 2'? Kein Problem. Wie auch immer, ich hatte gehofft, dass ich ein "hey check out this awesome blog post/nugget package" ausspucken könnte, aber es hört sich so an, als existiere es einfach nicht. –