Używanie MySql z Entity Framework 4 i Code-First Development CTP

Question

Pomyślałem, że poeksperymentuję trochę z pierwszym serwerem Scotta Guthriego latest post z programem Entity Framework 4. Zamiast używać serwera Sql, próbuję użyć MySql. Oto odnośne części mojego web.config (to jest 2 app Asp.Net MVC):

<connectionStrings> 
    <add name="NerdDinners" 
     connectionString="Server=localhost; Database=NerdDinners; Uid=root; Pwd=;" 
     providerName="MySql.Data.MySqlClient"/> 
    </connectionStrings> 
    <system.data> 
    <DbProviderFactories> 
     <add name="MySQL Data Provider" 
      invariant="MySql.Data.MySqlClient" 
      description=".Net Framework Data Provider for MySQL" 
      type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.2.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" /> 
    </DbProviderFactories> 
    </system.data> 

Podobnie jak w tutorialu Czekam EF4 wygenerować db dla mnie automatycznie. Zamiast tego generuje wyjątek ProviderIncompatibleException, z wewnętrznym wyjątkiem narzekającym, że baza danych NerdDinners nie istnieje.

Wystarczająco fair; Poszedłem i stworzył bazę danych MySql dla tego celu, aby sprawdzić, czy wszystko zadziała, i uzyskałem inny wyjątek ProviderIncompatibleException. Tym razem "DatabaseExists nie jest obsługiwany przez dostawcę".

Przyznam, że po raz pierwszy naprawdę zagłębiam się w Entity Framework (utknąłem głównie na Linq na Sql), a to wszystko działa na CTP wydanym w zeszłym tygodniu. To powiedziawszy, czy jest coś, co robię źle tutaj, czy znany problem, który można rozwiązać?

Answer 1

Dobrze, w końcu udało się to z kilkoma punktami zainteresowania.

• Nie można utworzyć DB, musi istnieć już
• Musisz utworzyć ciąg połączenia dla każdego konkursu DB przy użyciu nazwy DBContext (w powyższym przykładzie ConnectionString musi istnieć pod nazwą „NerdDinners”), nie tylko domyślny (w przeciwnym razie będzie używał SQL)
• Użyje nazwy nazwy DBSet, której używasz do zdefiniowania kontekstu jako nazwy tabeli, więc zachowaj ostrożność podczas nazywania ich.

W sumie długa droga, ale w końcu

** Aktualizacja Inną kwestią zasługującą na uwagę, podczas wdrażania witryny MVC MySQL będzie najbardziej jak trzeba dodać również DataFactory do swojej sieci .config. Zwykle z powodu różnicy w złączach MySql i obsługiwanych wersjach MySQL. (odpowiedź znaleźć za pośrednictwem innych źródeł po wielu głowy zarysowania) Wystarczy dodać:

<system.data> 
    <DbProviderFactories> 
     <add name="MySQL Data Provider" 
      invariant="MySql.Data.MySqlClient" 
      description=".Net Framework Data Provider for MySQL" 
      type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.3.6.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" /> 
    </DbProviderFactories> 
    </system.data> 

Jako oddzielne części do web.config upewniając się, aby ustawić numer wersji z MySQL.Data.dll Państwo wdrożyć z witryną (dobrym pomysłem jest również "kopiuj jako lokalny") biblioteki MySQL, aby zapewnić zgodność.

Answer 2

Kolejny punkt zainteresowania - Dodanie wpisu "Dostawca danych MySQL" do lokalnego komputera.config (C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Config \ machine.config w moim przypadku) można następnie połączyć się z instancją MySql za pomocą Visual Studio ...

Answer 3

To pytanie odpowiedź jest bardzo przydatne dla mnie migracji większego projektu EF z SQL do MySQL, więc myślałem, że chciałbym dodać moje notatki i mam nadzieję, że są przydatne:

Jak zauważył nazwa ciąg połączenia aby dopasować nazwę klasy, która rozszerza System.Data.Entity.DbContext.

Wydaje się, że nadal nie można tworzyć tabel w EF za pomocą złącza mySQL, ale można używać i modyfikować skrypty SQL do generowania tabel mySQL.Najłatwiej znalazłem to w komentarzach i na zewnątrz funkcji OnModelCreating na rozszerzonym DbContext w zależności od tego, czy kod był potrzebny do odtworzenia tabel. Jeśli stwierdzę, że robię to częściej, zamierzam rozwiązać ten problem za pomocą wtrysku zależności i mieć oddzielne klasy oparte na konfiguracji mySQL lub MSSQL.

Znalazłem łatwiejsze upewnienie się, że skrzynki dev i serwery miały poprawne złącze mySQL .dll spakowane w wersji niż bałagan z DbFactoryProviders w webconfig. Poprawne pakowanie w pakiecie budowania projektu/rozwiązania oznaczało, że potrzebowałem tylko linii ciągów połączenia, a nie linii DbFactoryProviders, które uważałem za trudne do pracy konsekwentnie na wielu maszynach.

Potrzebowałem zmienić wrażliwość przypadku identyfikatora mySQL z ustawienia, które miałem od 0 do 1. Bez tego ustawienia SQL, który łączył EF, nie mógł znaleźć tabel, które były tam z powodu mieszanych nazw moich obiektów w porównaniu do stałe tabele spraw, które tworzy mySQL.