Bug w Entity Framework Core 1.0 RTM!

Siemanko

Znalazłem buga (nie szukałem tylko sam o sobie dał znać w postaci błędnie działającej funkcjonalności po update’cie projektu do RTM) w EF Core 1.0 RTM, którego nie było we wcześniejszych wersjach tzn. RC1 i RC2.

Skip()’ując query nie includuje się lista z obiektami powiązanymi relacją

W moim przypadku jest to relacja 1 do wielu. W wolnym czasie sprawdzę jak jest z innymi, ale na razie skupmy się na wyżej wspomnianej.

Dla testów stworzyłem sobie całkiem nową aplikację aby mieć pewność, że to nie jakieś zaszłości z poprzednich wersji framework’a akurat u mnie w projekcie. Dodałem dwie klaski powiązane relacją:

classes

Zapisałem kilkadziesiąt rekordów przy czym każdy obiekt FirstModel powiązałem z 10cioma obiektami SecondClass.

Pytając o wszystkie i includując powiązaną tabelkę wszystko jest ok:

without

without_deb

 

Jednak kiedy zrobimy Skip()’a na query przed wykonaniem to lista z powiązanymi obiektami jest pusta:

skip

skip_deb

Ale jaja, nie? I to w RTM. Ciekawe ile jest jeszcze takich kwiatków.

Jakbyś był ciekaw co z dalej będzie z tym tematem to założyłem issue na github’ie.

Pjona!

 

Reklamy

Wracam po tygodniu przerwy. Podsumowanie dwóch miesięcy pracy nad projektem „Mobile Second Hand”

Siemanko

Chciałbym sobie schlebić i napisać, że pewnie zauważyłeś/łaś przerwę w moim blogowaniu oraz commitowaniu do repo na tydzień, jednak stąpam twardo po ziemi i godzę się z tym, że oprócz mnie samego nikt zapewne nie dostrzegł tej ogromnej luki w polskim internecie 😉 Jeśli jednak chcesz się ujawnić i pochwalić, że należysz do, bądź co bądź, elitarnego grona czytelników (jak czegoś mało tzn., że nie dla wszystkich ;)) to daj znać pod spodem. W dzisiejszym poście podsumowanko dwumiesięcznego blogowania i kodowania.

Staty z wodpressa

Nie wiem czy to śmiesznie mało, czy normalnie jak na początek, ale na dziś tj. 04.05.2016 wordpress zanotował przez niewiele ponad dwa mieisące 794 wyświetlenia i 439 gości na blogu.

1

Blogowanie

17 postów konkursowych i 2 posty niezwiązane z #dajsiepoznac opublikowane zaraz po stworzeniu bloga, ale jeszcze przed startem konkursu. Staram się nie pisać żadnego pierdololo, by tylko spełnić wymóg dwóch postów tygodniowo, dlatego przyjąłem zasadę: najpierw kodowanie potem blogowanie, aby mieć się czym dzielić. Posty publikuje w regularnych odstępach czasu w te same dni tygodnia – środa i niedziela.

Kodowanie

Android Studio – moim zdaniem bardzo young developer friendly środowisko. Wiele gotowych template’ów z których, świeżaki mogą szybko wgryzać się w Androida. Fajne funkcjonalności wspomagające refaktoryzację kodu i wiele innych.

Java – podobna do C#. W przypadku potrzeby przebranżowienia powinno pójść gładko

Asp.Net Core 1.0 – wersja RC1-final. Wszystko spoko. Wszystko wskazuje na to,  że będą musiał zrobić upgrade do wersji RC2 nightly builds ponieważ, chcę skorzystać z SignalR do zrobienia chatu dla userów aplikacji mobilnej. Mam nadzieję, że pójdzie w miarę gładko

Entity Framework Core 1.0 – trzeba zapomnieć o sposobie pracy z EF6. Brak automatycznej konfiguracji relacji wiele do wielu, kaskadowy zapis nie zawsze działa, usuwanie obiektów z kontekstu nie odzwierciedla się nigdzie do momentu wywołania SaveChanges(), bugi przy self reference i wiele innych ciekawostek. Zobaczę co poprawili w wersji RC2 jeśli uda mi się zupgradować projekt

Xamarin – fajne środowisko. Trochę wolne, ale .NETowe dobroci rekompensują wszystko. Przyspieszyłem z aplikacją mobilną od momentu rozstania z Android Studio, a kod jest dużo bardziej schludny i czysty.

Podsumowanie

Na pewno nie uda mi się skończyć projektu przed końcem konkursu. Im głębiej w las tym więcej chciałoby się funkcjonalności, a co za tym idzie jest więcej roboty przy niezmiennie małej ilości wolnego czasu. Po konkursie będę na pewno dalej pracował nad projektem. Czy blogował? Na pewno nie dwa razy w tygodniu, ale może raz na jakiś czas opowiem jakiś dowcip 😉

Pjona!

Kilka słów o EF Core 1.0

Siemanko.

Dziś troszkę o EF Core 1.0 (EF 7 do niedawna), które wykorzystuję w projekcie Asp.Net Core jako część backend’u dla aplikacji mobilnej Mobile Second Hand. Troszkę, bo nie poznałem jeszcze wszystkich nowości w tej wersji Microsoft’owego ORM’a i to co dziś przeczytasz będzie to głównie opis największych różnic między w.w. wersją, a poprzednią czyli EF6.

Gotowiec Entity Framework Identity.

Jak kiedyś wspomniałem, projekt Asp.Net Core założyłem z wbudowanego w Visual Studio template’a – Web Aplication – z zaznaczoną opcją Individual User Accounts co skutkuje tym, że z automatu jest skonfigurowany dostęp do danych wraz z obsługą autentykacji. Wystarczy tylko w pliczku appsettings.json głównego projektu wpisać connection string do bazy, z którą chcemy pracować. W moim przypadku:

q

Tak jak w poprzedniej wersji Entity Framework, jeśli baza podana w connection stringu nie istniała, wystarczyło utworzyć nowy obiekt DbContext’u aby ORM tę bazę utworzył, dlatego poszedłem tym samym tropem – utworzyłem obiekt Usera i spróbowałem zapisać. Niestety ku mojemu zdziwieniu nic z tego nie wyszło. Dostawałem wyjątek, że EF nie może się zalogować do serwera bazy danych z wykorzystaniem poświadczeń podanych w connection stringu. Było to tym bardziej frustrujące bo logowanie do SQL’a mam domenowe i tak też podałem w connection stringu. Po pewnym czasie i paru chujach skierowanych w stronę monitorów doszedłem do tego, że trzeba się ręcznie upewnić o istnieniu bazy i wtedy EF Core ją utworzy jeśli jej nie ma. Należy to zrobić wpisując jedną linijkę na końcu metody Configure w klasie Startup.cs.

2

Oczywiście context to nazwa parametru dla DbContext’u aplikacji jaki przyjmuje metoda Configure (dlatego równie dobrze może być dupa.Database.EnsureCreated()), a owy DbContext jest wstrzykiwany z użyciem Dependency Injection.

Brak Initializer’ów.

W poprzedniej wersji EF do współpracy z DbContext’em były definiowane i wykorzystywane tzw. Initializer’y. To one określały co ma się dziać z bazą danych. I tak:

  • CreateDatabaseIfNotExists – tworzył bazę gdy jej nie było – dlatego w poprzedniej wersji EF baza była z automatu tworzona gdyż ten Initializer był domyślny
  • DropCreateDatabaseIfModelChanges – usuwał i tworzył bazę gdy uległ zmianie, którykolwiek z modeli podanych w DbSet’cie
  • DropCreateDatabaseAlways – za każdym uruchomieniem aplikacji i jej pierwszym odwołaniu się do bazy ta była usuwana i tworzona na nowo
  • CustomDbInitializer – możliwość napisania swojego gdy żaden z powyższych nie odpowiadał (np. migracja do najnowszej wersji bazy w przypadku korzystania z ręcznych migracji)

Oczywiście wykorzystując te initilizer’y mogliśmy wypełniać bazę jakimiś danymi, ale to było w poprzedniej wersji. Teraz są tylko ręczne migracje.

Tylko ręczne migracje

W poprzedniej wersji mogliśmy nie korzystać z migracji, włączyć automatyczne migracje bądź ręcznie migrować schemat bazy. Teraz nie ma takiego wyboru i jedynym dostępnym sposobem do obsługi schematu bazy są ręczne migracje. Migracjami operujemy z poziomu command line’a. W projekcie głównym muszą być zainstalowane EntityFramework.Commands, aby można było ich używać w wierszu poleceń (w gotowej aplikacji z template’a już wszystko jest). Jeśli masz w solucji kilka projektów to musisz pamiętać aby za pomocą cd przejść do projektu głównego, gdzie są zainstalowane EntityFramework.Commands oraz koniecznie wpisać dnvm use 1.0.0-rc1-final (póki jest jeszcze wersja RC1 frameworka Asp.net Core) bo zacznie sypać wyjątkami, jeśli spróbujesz korzystać z komend EF np. dnx ef –help.

Podsumowanie

Tak jak wspomniałem we wstępie to tylko pierwsze spojrzenie na nową wersję EF. Jeśli jesteś ciekaw jak od zera dodać do projektu nowe EF to odwiedź matczyną stronę Asp.Net Core gdzie jest wszystko elegancko opisane.

W niedzielę napiszę o pierwszych walkach z Xamarinem ponieważ jak możesz się dowiedzieć z poprzedniego postu porzuciłem projekt w Android Studio i zaczynam od zera w Xamarinie.

Pjona!