Entity Framework 6 provider wechsel–MSSQL und PostGreSql 2.1.1.0


Vor einiger Zeit habe ich erläutert wie man das gleiche EF Model für eine MSSQL Datenbank und MySQL Datenbank verwenden kann. Das “gleiche” geht natürlich auch mit anderen SQL Datenbanken wie z.B. PostGreSql. Nur das die Verwendung für PostGreSql mit einigen Tücken auf sich aufmerksam machte bei der Umsetzung. Wie man eine normale PostGreSql Datenbank mit .NET EF anspricht habe ich bereits in meinem Artikel “Postgres Datenbank und Entity Framework mit npgsql” beschrieben. Im Aktuellen Artikel werde ich auf die Grundlagen der beiden bereits geschriebenen Artikel verweisen und hier nur noch auf die entstandenen Probleme eingehen, denn das Vorgehen ist hier durchaus ähnlich.

Wie bereits bekannt, dient als Grundlage eine MSSQL Datenbank die bereits in einem EDMX abgebildet ist. Wir müssen dann die passende SSDL für die zugehörige PostGreSql Datenbank ergänzen. Als erstes müssen wir also unsere Tabellen aus der MSSQL Datenbank auch in der PostGres Datenbank anlegen und hier aufpassen, das auch nur die kompatiblen Datentypen verwendet werden die beide SQL Systeme und .NET verstehen.

Ich habe bei der Datenbankkonvertierung auf die Trial Version von MS SQL to PostgreSQL gesetzt, da ich keine Datensätze zu migrieren hatte und die Fremdschlüsselbeziehungen per “Hand” nachgetragen habe, denn die Trial Version hat hier einige Einschränkungen. Außerdem wurde beim Konvertieren kein Autoinkrement konvertiert, was ebenfalls angepasst werden musste mit Hilfe des Datentyps “serial” and “bigserial” in PostGreSql.

Nachdem man zwei “gleiche” Datenbanken hat für MSSQL und PostGres kann man mit Hilfe des Tools “edmGen” die passenden Daten für die PostGres Datenbank erstellen, wozu auch unsere SSDL gehört, die wir für den Providerswitch zwischen MSSQL und PostGreSql benötigen. Damit edmGen ausgeführt werden kann müssen die entsprechenden npgsql Providerdaten im GAC registriert werden (die Dateien Selbst kann man sich inzwischen auf über NuGet ziehen). Für EF6 wird hier aber zusätzlich noch die “Npgsql.EntityFrameworkLegacy.dll” und die “Npgsql.EntityFramework.dll” im GAC benötigt, die zusätzlich zur “Npgsql.dll” registriert werden müssen, wie bereits in einem meiner älteren Artikel erläutert. Da es evtl. zu Kompatibilitätsproblemen führen kann zwischen EF6 und der “Npgsql.EntityFrameworkLegacy.dll”, da diese eigentlich für alle EF Version Kleiner 6.0 gedacht ist, habe ich mir hier ein Beispielprojekt angelegt in dem ich per NuGet die aktuelle Version der Legacy Variante kopiere und dann diese Datei im Hauptprojekt direkt verweise in dem ich EF6 verwende. Denn die Legacy Datei wird nur für das Erstellen der Modeldaten mit edmGen verwendet. Nachdem man mit edmGen die passenden Modeldaten für unsere PostGres Datenbank erstellt hat benötigen wir hier nur die SSDL. Die SSDL einfach im passenden Projekt wo z.B. unser EDMX ist ablegen und als Resource einbetten. Wie der passende Connectionstring auszusehen hat, habe ich bereits in einem meiner anderen Artikel beschrieben.

Die SSDL muss aber noch “angepasst” werden, denn aktuell würde hier die Fehlermeldung:

„Schema specified is not valid. Errors: error 2102: The version of EdmItemCollection must match the version of StoreItemCollection.“

kommen, ich denke es ist noch ein Bug in den aktuellen npgsql 2.1.1.0 Version für EF6. Damit dieser Fehler nicht auftritt, muss in der SSDL für PostGres der gleiche xmlns Namespace eingetragen sein wie in der SSDL für MSSQL. Wenn dieser aktuell verglichen wird:

MSSQL im Schema Tag der SSDL: xmlns=“http://schemas.microsoft.com/ado/2009/11/edm/ssdl”

PostGreSQL im Schema Tag der SSDL: xmlns=“http://schemas.microsoft.com/ado/2009/02/edm/ssdl“

Hier muss zwingend der Wert von “/02/” auf “/11/” geändert werden, d.h. in der PostGres SSDL muss der gleiche xmlns Eintrag stehen wie in der MSSQL SSDL.

Jetzt muss nur noch die App.Config entsprechend angepasst werden auf npgsql und Entity Framework 6 und schon funktioniert das ganze wie bei MySql.

Hinweis: Ich hatte bei der Konvertierung der Datenbank noch Probleme mit einigen Datentypen die nicht “richtig” konvertiert wurden, dann erhält man z.B: die folgende Fehlermeldung:

testModel.msl(343,12) : error 2019: Member Mapping specified is not valid. The type ‚Edm.Double[Nullable=False,DefaultValue=]‘ of member ‚costs‘ in type ‚test.cost‘ is not compatible with ‚Npgsql.float4[Nullable=False,DefaultValue=]‘ of member costs‘ in type ‚test.Store.cost‘.

Hier muss nach einem passenden Datentyp gesucht werden der in beiden SQL Versionen “übereinstimmt”.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s