Migracja bazy danych w EF

Home

Już dawno temu pisałem o zastosowaniu RavenDB w swoim projekcie. Początkowo byłem zadowolony z tego wyboru ale jakiś czas temu zdecydowałem się przejść na Entity Framework + SQLCe. Czemu? To temat ta cały post, tak w skrócie to zirytowało mnie to, że RavenDB stara się być mądrzejszy od programisty oraz to jak trudno osiągnąć w nim niektóre rzeczy. Nie twierdzę, że RavenDB jest zły, ale tak jak inne dokumentowe bazy danych nie do wszystkiego się nadaje.

Wracając do tematu, przechodząc do EF zdecydowałem się wykorzystać podejście code first. Wcześniej tego nie próbowałem i muszę powiedzieć, że byłem bardzo zadowolony, migracja odbyła się w miarę bezboleśnie. Swoją drogą zaprocentowała początkowa decyzja aby ukryć technologię dostępu do danych za dobrze określonym interfejsem. Dzięki temu zmiany musiałem wprowadzić w niewielu miejscach. Nie ma jednak róży bez końców. Kiedy po jakimś czasie chciałem dodać nową właściwość do swoich encji otrzymywałem błąd:

The model backing the context has changed since the database was created...

Za pierwszym razem poradziłem sobie z tym tworząc bazę danych od początku i importując dane ale na dłuższą metę byłoby to uciążliwe. Zacząłem kombinować nad rozwiązaniem, które zmieniłoby schemat bazy danych przed użyciem EF. Wtedy natknąłem się na artykuł opisujący to zagadnienie i był to strzał w dziesiątkę. Oto krótki opis co zrobiłem:.

• Dodałem nową właściwość do encji.
• Zmodyfikowałem logikę biznesową.
• Uruchomiłem Package Manager Console.
• Jako Default project wybrałem projekt, z klasę dziedziczącą po DbContext. Jeśli takich klas jest więcej zostanie zgłoszony błąd.
• Wydałem polecenie Enable-Migrations.
• Do projektu został dodany katalog Migrations, a w nim klasa Configuration.
• Wydałem polecenie Add-Migration tj. Add-Migration AddColumn.
• W projekcie została utworzona klasa AddColumn dziedzicząca po DbMigration. Dla mnie interesujące była metoda Up, w której umieściłem kod odpowiedzialny za uaktualnienie bazy danych. Wyglądało to w następujący sposób:
  
  

  public override void Up()
  {
     AddColumn("TranslationEntities", "Translation2", c => c.String(true, maxLength: 4000, storeType: "nvarchar"));
  }
  

  
  Metoda AddColumn to metoda klasy DbMigration. Jest ich dużo więcej np.: AddForeignKey, CreateIndex czy RenameColumn.
• Na koniec użyłem klasy MigrateDatabaseToLatestVersion w celu zainicjowania bazy danych:
  
  

  Database.SetInitializer(new MigrateDatabaseToLatestVersion<ExpressionsDataContext, Configuration>());

  
  
• Przy kolejnym uruchomieniu aplikacji zadziały się dwie rzeczy. Do tabelki TranslationEntities została dodana nowa kolumna oraz utworzona została nowa tabela __MigrationHistory. Dzięki tej nowej tabelce EF będzie śledził historię wprowadzanych zmian i nie uruchomi tej samej migracji więcej niż raz.

To bardzo prosty przykład. Jestem ciekawy jak ta funkcjonalność spisuje się w bardziej skomplikowanych scenariuszach. Czy macie jakieś doświadczenia?

WPF i opóźnione wykonanie (deferred execution)

Home

Najpierw spójrzmy na poniższy fragment XAML'a z prostą implementacją combobox'a z wieloma kolumnami:

...
<ComboBox ItemsSource="{Binding PerformedAnalysis}" SelectedValuePath="Id" SelectedValue="{Binding SelectedItem}">
 <ComboBox.ItemTemplate>
  <DataTemplate>
   <StackPanel Orientation="Horizontal">
    <Border BorderThickness="1" BorderBrush="Black" Margin="1" Padding="1">
     <TextBlock Text="{Binding Id}" Width="100"></TextBlock>
    </Border>
    <Border BorderThickness="1" BorderBrush="Black" Margin="1" Padding="1">
     <TextBlock Text="{Binding Name}" Width="500"></TextBlock>
    </Border>
   </StackPanel>
  </DataTemplate>
 </ComboBox.ItemTemplate>
</ComboBox>
...

Oraz kod z view model'u zasilający tą kontrolkę. Kod ten używa Entity Framework, a Context to nic innego jak obiekt dziedziczący po ObjectContext.

...
private IEnumerable _PerformedAnalysis = null;

public IEnumerable PerformedAnalysis
{
    get
    {
        try
        {
            if (_PerformedAnalysis == null)
            {
                _PerformedAnalysis = 
                        from a in Context.Analyses
                        orderby a.Id
                        select new { Id = a.Id, Name = a.Name };
            }
        }
        catch (Exception ex)
        {
            ServiceProvider.GetService<IWindowService>().ShowError(ex);
            _PerformedAnalysis = new[] { new { Id = -1, Name = ex.Message } };
        }

        return _PerformedAnalysis;
    }
}
...

Kod ten zawiera dość poważną usterką. Jaką? Ktoś może powiedzieć, że błędem jest użycie bezpośrednio EF'a, zamiast ukryć dostęp do danych za warstwą interfejsów. W prostej aplikacji nie ma to moim zdaniem sensu, w bardziej rozbudowanej też można nad tym dyskutować. Ktoś może również powiedzieć, że przy bindowaniu należy użyć ObservableCollection. W tym jednak przypadku do kolekcji nie będą dodawane lub usuwane żadne elementy, więc nie jest to konieczne.

Błąd jest dużo poważniejszy i może spowodować, potocznie mówiąc, wywalenie się całej aplikacji. Odpowiedzmy na pytanie co się stanie jeśli nawiązanie połączenia z bazą danych jest niemożliwie? Oczywiście zostanie zgłoszony błąd ale czy zostanie obsłużony? Pozornie powyższy kod poradzi sobie z takim scenariusz, przecież zawiera blok try/catch.

Zapomniano jednak o tzw. opóźnionym wykonaniu (ang. deffered execution) czyli o tym, że właściwe zapytanie do bazy danych zostanie wykonane dopiero kiedy dane będą rzeczywiście potrzebne czyli kiedy silnik WPF wykona bindowanie. Inaczej mówiąc wyjątek spowodowany brakiem połączenia z bazą danych zostanie rzucony gdzieś wewnątrz silnika WPF. Będzie można go przechwycić korzystając z DispatcherUnhandledException ale z perspektywy działania aplikacji to już nic nie da.

Jak to często bywa naprawienie błędu jest bardzo proste. Należy zapewnić wykonanie zapytania jeszcze w naszym kodzie np.:

...
 _PerformedAnalysis = 
  (from a in Context.Analyses
  orderby a.Id
  select new { Id = a.Id, FileName = a.FileName, Start = a.StartTime }).ToList();
...

RavenDB (cz. 7) - HttpListenerException

Home

Ten post będzie krótki i zwięzły. Jakiś czas temu kiedy włączyłem UAC (User Account Control) ze zdziwieniem zauważyłem, że moja aplikacja używająca Raven DB nie działa. Przy wywołaniu metody DocumentStore.Initialize rzucany był wyjątek HttpListenerException. Po wyłączeniu UAC błąd nie występował.

Z problem łatwo sobie poradzić nadając użytkownikowi, jaki uruchamia aplikację, uprawnienia do nasłuchiwania na porcie używanym przez bazę danych. Można to zrobić przy pomocy narzędzia httpcfg lub netsh tak jak to zostało opisane w tym dokumencie. Co jednak najlepsze Raven DB dostarcza gotowej klasy NonAdminHttp, w bibliotece Raven.Database.dll, która rozwiązuje ten problem. Poniżej przykład użycia.

...
NonAdminHttp.EnsureCanListenToWhenInNonAdminContext(Store.Configuration.Port);

Store.Initialize();
...

A tak w ogóle to warto zajrzeć, przy pomocy jakiegoś deasemblera, do wnętrza metody EnsureCanListenToWhenInNonAdminContext i zobaczyć jak została zaimplementowana.

Podsumujmy co już umiemy:

• Osadzić Raven DB w aplikacji hostującej.
• Zainicjować Raven DB.
• Skonfigurować dostęp do Raven Studio i API REST'owego.
• Tworzyć obiekty POCO jakie mogą zostać umieszczone w Raven DB.
• Dodawać/usuwać/modyfikować dokumenty.
• Zadawać proste i te trochę bardziej skomplikowane zapytania.
• Utworzyć indeks.
• Skorzystać z algorytmu Map/Reduce.
• Skorzystać z zapytań Lucene.
• Wymusić zwrócenie przez zapytanie aktualnych danych.
• Sterować tym, które właściwości zostaną zapisane do bazy danych.
• Rozwiązać kłopoty związane z IntelliTrace i Raven DB.
• Rozwiązać problem z HttpListenerException.

RavenDB (cz. 6) - małe kłopoty z IntelliTrace

Home

Ten post będzie krótki ale poruszę w nim sprawę, o której dobrze wiedzieć aby potem nie kląć pod nosem i nie wołać o pomstę do nieba, bo coś nagle przestało działać.

Otóż Raven DB, z powodów opisanych dalej, nie współpracuje dobrze z historycznym debugerem IntelliTrace pracującym w trybie rozszerzonym (IntelliTrace events and call information). Jest to tryb, w którym IntelliTrace monitoruje wywołania metod, konstruktorów, dostęp do właściwości itd. oraz dodatkowo tzw. zdarzenia diagnostyczne, które są monitorowane również w trybie podstawowym (pisałem o tym w poście).

Tak naprawdę problem nie jest związany bezpośrednio z Raven DB ale z jedną z bibliotek z jakich korzysta. Nie współpracuje to zresztą eufemizm, bo powinienem napisać nie działa, wywala się... Jeśli uruchomimy aplikację korzystającą z Raven DB pod kontrolą IntelliTrace w pewnym momencie (próba zapisu, odczytu, utworzenia indeksu) otrzymamy wyjątek VerificationException z komunikatem Operation could destabilize the runtime.. Call stack zaprowadzi nas natomiast do biblioteki Newtonsoft.Json.

IntelliTrace wstrzykuje w kod monitorowanych programów własne instrukcje i to najpewniej w tym przypadku powoduje błąd. Z problemem można sobie jednak łatwo poradzić mówiąc IntelliTrace, aby ignorował tą bibliotekę. W tym celu otwieramy okno opcji Tools -> Options, wybieramy menu IntelliTrace i dalej Modules, klikamy przycisk Add..., i w polu tekstowym wpisujemy *Newtonsoft*, a na koniec zatwierdzamy.

Podsumujmy co już umiemy:

• Osadzić Raven DB w aplikacji hostującej.
• Zainicjować Raven DB.
• Skonfigurować dostęp do Raven Studio i API REST'owego.
• Tworzyć obiekty POCO jakie mogą zostać umieszczone w Raven DB.
• Dodawać/usuwać/modyfikować dokumenty.
• Zadawać proste i te trochę bardziej skomplikowane zapytania.
• Utworzyć indeks.
• Skorzystać z algorytmu Map/Reduce.
• Skorzystać z zapytań Lucene.
• Wymusić zwrócenie przez zapytanie aktualnych danych.
• Sterować tym, które właściwości zostaną zapisane do bazy danych.
• Rozwiązać kłopoty związane z IntelliTrace i Raven DB.

RavenDB (cz. 5) - JsonIgnore

Home

Kiedy zapisujemy w Raven DB jakiś obiekt, to domyślnie w bazie zostaną zapisane wartości wszystkich jego właściwości, publicznych i prywatnych, a także tych tylko do odczytu. Nie zawsze jest to pożądane, niektóre rzeczy chcemy po prostu pominąć. W takiej sytuacji z pomocą przychodzi nam atrybut JsonIgnore. Właściwości oznaczone tym atrybutem będą pomijane przez silnik serializujący, a znajdziemy go w dll'ce Newtonsoft.Json.dll używanej przez Raven DB.

public class Test
{
 public int Id { get; set; }
 public int string WillBeSavedToRavenDB{ get; set; }
 [JsonIgnore]
 public int string WillBeIgnoredByRavenDB{ get; set; }
}

Użycie atrybutu JsonIgnore może być jednak problematyczne. W swoich projektach używam klasy BaseEntity, która jest klasą bazową dla innych encji np.: ExpressionEntity, TranslationEnity itd. Klasa ta zdefiniowana jest w osobnej bibliotece nie mającej niż wspólnego z Raven DB. W szczególności wykorzystuję ją w projektach, które korzystają z relacyjnej bazy danych.

Łatwo się domyślić, że klasa ta ma właściwości, których nie chcę zapisywać w dokumentowej, lub innej, bazie danych. Innymi słowy wymaga to abym oznaczył je atrybutem JsonIgnore czyli dodał do projektu zawierającego tą klasę referencję do biblioteki Newtonsoft.Json.dll. Nie chciałem jednak tego robić, bo jest to atrybut specyficzny dla Raven DB i biblioteka ta nie jest potrzebna we wszystkich moich projektach.

Problem rozwiązałem oznaczając interesujące właściwości jako virtual, umożliwiając tym samym ich przedefiniowanie (ang. override) i oznaczenie atrybutem JsonIgnore w projektach używających Raven DB.

public class BaseEntity
{
 public virtual string Name { get; set; }
}

public class TestEntity : BaseEntity
{
 public int Id { get; set; }
 public string Id { get; set; }
 [JsonIgnore]
 public override string Name
 {
  get { return base.Name; }
  set { base.Name = value; }
 }
}

Niestety z moich obserwacji wynika, że opisane podejście nie działa z właściwościami protected. Jeśli przedefiniowujemy taką właściwość i oznaczamy atrybutem JsonIgnore to zostanie to zignorowane, a jej wartość zostanie zapisana w bazie danych. Czyżby bug w Raven DB?

Podsumujmy co już umiemy:

• Osadzić Raven DB w aplikacji hostującej.
• Zainicjować Raven DB.
• Skonfigurować dostęp do Raven Studio i API REST'owego.
• Tworzyć obiekty POCO jakie mogą zostać umieszczone w Raven DB.
• Dodawać/usuwać/modyfikować dokumenty.
• Zadawać proste i te trochę bardziej skomplikowane zapytania.
• Utworzyć indeks.
• Skorzystać z algorytmu Map/Reduce.
• Skorzystać z zapytań Lucene.
• Wymusić zwrócenie przez zapytanie aktualnych danych.
• Sterować tym, które właściwości zostaną zapisane do bazy danych.

RavenDB (cz. 4) - zapytania 2

Home

Ten post to kontynuacja poprzedniego postu dotyczącego zapytań w Raven DB.

Contains == Equals !!!

Jedną z funkcjonalności jaką chciałem zaimplementować w swoim programie było wyszukiwanie wyrażeń/tłumaczeń zawierających podany ciąg znaków. Brzmi prosto ale nie obyło się bez problemów. Otóż okazało się, że Raven DB traktuje wywołanie metody String.Contains jako String.Equals, chyba że do poszukiwanego ciągu znaków dodamy gwiazdki. Na przykład zamiast s.Contains("kot") użyjemy s.Contains("kot*"), s.Contains("*kot") lub s.Contains("*kot*") w zależności czy poszukiwane wyrażenie ma znajdować się na początku, na końcu lub w środku.

string textToFind = String.Format("*{0}*", textToFind);

var res = 
 from ex in session.Query<ExpressionEntity>()
 where ex.Expression!= null && ex.Expression.Contains(textToFind) || ex.Translations.Any(t => t.Translation != null && t.Translation.Contains(textToFind))
 orderby ex.Expression
 select ex

Pozostaje jeden problem, którego niestety nie udało mi się rozwiązać. Ten kod nie zadziała jeśli szukany tekst zawiera białe znaki. Załóżmy, że na liście naszych wyrażenie mamy wyrażenie Ala ma kota. Jeśli spróbujemy wyszukać "*Ala*", "*ma*", "*kota*" otrzymamy poprawny wynik. Jeśli natomiast spróbujemy wyszukać całe wyrażenie "*Ala ma kota*" zapytanie zwróci nam pustą listę. Co dziwniejsze jeśli nie użyjemy gwiazdek czyli zlecimy wyszukanie "Ala ma kota" wyrażenie zostanie znalezione.

Ale co, jeśli szukam podwyrażenia "Ala ma" lub "ma kota"? Nie jest to duże pocieszenie ale Raven DB poradzi sobie z "Ala ma*" (z "*ma kota" już nie). Moim zdaniem sugeruje to, że wewnętrznie Raven DB do wyszukiwania używa jakiejś struktury opartej o prefixy.

Małe ostrzeżenie

W jednym z zapytań chciałem użyć metody String.Equals ale zakończyło się to wyjątkiem NullReferenceException. Sądzę, że jest to związany z użyciem metod statycznych bo kiedy użyłem metody instancyjnej np.: ex.Expression.Equals(textToFind, StringComparison.InvariantCultureIgnoreCase) obyło się bez błędów.

Stale Data

Jedną z głównych idei przyświecających twórcom Raven DB było zapewnić aby pytający o dane jak najszybciej uzyskał odpowiedź nawet jeśli oznaczałoby to zwrócenie nieaktualnych, przestarzałych danych. Używając Raven DB trzeba być na to przygotowanym nawet pracując z małą ilością danych. W moim przypadku baza danych zawiera ok. 600 dokumentów, nie całe 0.5 MB po wyeksportowaniu do pliku XML i obserwuję ten efekt.

Na przykład na początku moja aplikacja wyświetlała liczbę wyrażeń obok etykiety z nazwą języka. Jeśli jednak użytkownik importował do aplikacji wiele wyrażeń to operacja zapisywania danych, odświeżania indeksów itd. po stronie bazy danych trwała na tyle długo, że wyliczona liczba wyrażeń nie zgadzała się ze stanem faktycznym.

• Użytkownik rozpoczyna import wyrażeń.
• Zakończenie importu z perspektywy aplikacji/użytkownika.
• Obliczenie liczby wyrażeń w poszczególnych językach.
• ...
• Faktyczne zakończenie importu po stronie bazy danych.

W tej chwili do problemu podchodzę tak, że liczbę słów w danym języku wyświetlam na życzenie. Jeśli takie zachowanie Raven DB jednak nam przeszkadza to należy explicite powiedzieć, że nie śpieszy się nam i możemy poczekać na aktualne dane np.:

var res = 
 from ex in session.Query<ExpressionEntity>().Customize(a => a.WaitForNonStaleResults())
 select ex;

Lucene

Raven DB jako silnika indeksujący używa technologii Lucene .NET. Co ciekawe umożliwia zdefiniowanie zapytań w składni jaką posługuje się ten silnik. Bezpośrednie użycie Lucene może wyglądać tak:

var res = session.Advanced.LuceneQuery<ExpressionEntity>().Where(luceneQuery);

Gdzie luceneQuery to po prostu ciąg znaków zawierający zapytanie w składni zrozumiałej dla Lucene. Może to się przydać kiedy będziemy chcieli zadać zapytanie nie obsługiwane przez "LINQ to Raven DB".

Indeksy

Jeszcze parę słów o indeksach. Termin ten przewinął sie już kilka razy. Pracując z Raven DB trzeba sobie przede wszystkim uświadomić, że tutaj indeksy różnią się od indeksów używanych w bazach relacyjnych. Moim zdaniem dwie różnice są fundamentalne. Po pierwsze Raven DB indeksuje zapytania, a nie dane. Indeks definiujemy definiując zapytanie, a nie wskazując na przykład atrybut dokumentu, który ma zostać zaindeksowany.

Po drugie Raven DB używa indeksów przy wykonywaniu każdego zapytania nawet jeśli taki indeks nie został zdefiniowany. W takiej sytuacji tworzony jest indeks dynamiczny. Druga grupa indeksów to indeksy statyczne, zdefiniowane explicite przez użytkownika na podstawie jego wiedzy o zadawanych pytaniach. Tymczasowe indeksy dynamiczne mogą zostać zamienione na stałe jeśli Raven DB zauważy, że taki indeks jest często używany.

Podsumowanie

O ile sposób realizacji podstawowych operacji dodaj/usuń/zmodyfikuj na dokumentach bardzo chwaliłem ze względu na jego prostotę i niski koszt wejścia to o raportowaniu/zapytaniach nie mogę już tego powiedzieć. Z jednej strony nie jest to żaden rocket science ale z drugiej nie jest to już "bułka z masłem" i wymaga znajomości rożnych sztuczek i specyfiki Raven DB. Jeśli uwzględnić, że zapytania jakich użyłem były bardzo proste, a pomimo to sprawiły mi sporo kłopotów to obawiam się, chociaż są to tylko moje przypuszczenia, że realizacja skomplikowanych raportów może być w Raven DB bardzo nietrywialna.

Podsumujmy co już umiemy:

• Osadzić Raven DB w aplikacji hostującej.
• Zainicjować Raven DB.
• Skonfigurować dostęp do Raven Studio i API REST'owego.
• Tworzyć obiekty POCO jakie mogą zostać umieszczone w Raven DB.
• Dodawać/usuwać/modyfikować dokumenty.
• Zadawać proste i te trochę bardziej skomplikowane zapytania.
• Utworzyć indeks.
• Skorzystać z algorytmu Map/Reduce.
• Skorzystać z zapytań Lucene.
• Wymusić zwrócenie przez zapytanie aktualnych danych.

RavenDB (cz. 3) - zapytania

Home

Wstęp

W tej części serii poświęconej Raven DB napiszę o zapytaniach, pobieraniu danych. Temat sam w sobie jest bardzo obszerny i to, co napiszę, to tylko szczyt góry lodowej. Większość tematów po prostu zasygnalizuje, ale sądzę, że dobrze pokaże, jak to wygląda z Raven DB.

Podstawy

Podstawowe zapytania zadajemy w bardzo prosty sposób i robimy to otwierając najpierw sesję pracy z bazą np.:

using (var session = Store.OpenSession())
{
 var res = from ex in session.Query<ExpressionEntity>()
    select ex;
 ...
}

Aby pobrać listę dokumentów użyłem metody Query określając jaki typ dokumentów mnie interesuje. Dla przypomnienia klasa ExpressionEntity reprezentuje wyrażenie i jego tłumaczenia. Jest to ta sama klasa, która wcześniej posłużyła mi do umieszczenia danych w bazie.

Jeszcze jeden przykład. Tym razem pobieram listę dokumentów by na jej podstawie określić listę różnych kategorii, jakie zdefiniowano dla wszystkich wyrażeń.

var res = (from e in session.Query<ExpressionEntity>()
    where e.Category != null
    orderby e.Category
    select e.Category).Distinct();

Jak widać podstawowe zapytania wykonuje się bardzo łatwo.

Stronicowanie

Przy dużej liczbie dokumentów przydatne okaże się stronicowanie. To też nie jest trudne do zrealizowania:

var res = (from ex in session.Query<ExpressionEntity>()
    orderby ex.Expression
    select ex).Skip(index * pageSize).Take(pageSize).ToList();

Użyta w kodzie zmienna index to indeks strony do pobrania (w numerowaniu od zera), a pageSize to oczywiście wielkość strony liczona w liczbie dokumentów. Metoda Skip pozwala więc na przeskoczenie do konkretnej strony, a metoda Take na pobranie takiej liczby dokumentów jaka mieści się na stronie.

Robi się trudniej

Jedną z funkcjonalności, jakie chciałem mieć w swoim programie LanguageTrainer, było zliczanie liczby wyrażeń posiadających tłumaczenie w danym języku. Brzmi prosto, prawda? Pierwsza moja próba wyglądała tak:

 var count = 
 (from ex in session.Query<ExpressionEntity>()
 from t in ex.Translations
 where t.Language == selectedLang && !String.IsNullOrEmpty(t.Translation) 
 select 1).Count();

Zmienna selectedLang zawiera interesujący nas język. Wykonanie takiego zapytania zakończy się wyjątkiem NotSupportedException z komunikatem Method not supported: SelectMany. A więc może coś takiego:

var count =
 (from ex in session.Query<ExpressionEntity>()
 where ex.Translations.Any(t => t.Language == selectedLang && !String.IsNullOrEmpty(t.Translation))
 select 1).Count();

Tym razem zakończy się wyjątkiem z komunikatem Method not supported: IsNullOrEmpty. No cóż IsNullOrEmpty łatwo zastapić zwykłym porównaniem. Spróbujmy więc jeszcze raz:

var count = 
 (from ex in session.Query<ExpressionEntity>()
 where ex.Translations.Any(t => t.Language == selectedLang && t.Translation != null && t.Translation != String.Empty)
 select 1).Count();

To też nie zadziała i znowu zakończy sie błędem, tym razem z komunikatem Node not supported: Constant. Jeszcze jednak próba i w końcu zadziałało:

var count = 
 (from ex in session.Query<ExpressionEntity>()
 where ex.Translations.Any(t => t.Language == selectedLang && t.Translation != null && t.Translation != String.Empty)
 select ex).Count();

Nie jest to skomplikowane ale wymaga znajomości kilku "trików", nie jest do końca intuicyjne.

MapReduce

Do opisanego powyżej problemu można też podejście w Raven DB w inny sposób, a mianowicie stosując algorytm MapReduce. W ten sposób wykonując jedno zapytanie otrzymamy wyniki dla wszystkich języków za jednym razem. W Raven DB robimy to definiując indeks (jeszcze o tym napiszę):

public class TranslationsCounter : AbstractIndexCreationTask<ExpressionEntity, TranslationsCounter.ReduceResult>
{
 public class ReduceResult
 {
  public Languages Lang { get; set; }
  public int Count { get; set; }
 }

 public TranslationsCounter()
 {
  Map = docs => from doc in docs
   from t in doc.Translations
   select new { Lang = t.Language, Count = String.IsNullOrEmpty(t.Translation) ? 0 : 1 };

  Reduce = results => from t in results
   group t by t.Lang
   into g
   select new { Lang = g.Key, Count = g.Sum(x => x.Count) };
 }
}

i zadanie zapytania przy jego użyciu np.:

public IDictionary<Languages,int> CountExpressionsByLanguage()
{
 using (var session = Store.OpenSession())
 {
  var dict = new Dictionary<Languages, int>();

  foreach(var res in session.Query<TranslationsCounter.ReduceResult, TranslationsCounter>())
  {
   dict.Add(res.Lang, res.Count);
  }

  return dict;
 }
}

To jeszcze nie koniec. Do tematu wrócę w kolejnym poście.

RavenDB (cz. 2) - podstawowe operacje na dokumentach

Home

Wstęp

W drugim poście poświęconym Raven DB opiszę jak wykonywać podstawowe operacje (zapisz/usuń/zmień) na dokumentach. Ale czym jest dokument? Nie wiem jaka jest formalna definicja ale ja na dokumenty patrzę po prostu jak na obiekty zapisane (zserializowane) w formacie JSON. Poniżej przykład takiego dokumentu z mojego pet project, który odpowiada obiektowi klasy reprezentującej wyrażenie i jego tłumaczenia.

{
  "Category": "Geografia",
  "Expression": "wioska",
  "Translations": [
    {
      "Language": "Language1",
      "Translation": "Dorf",
      "GoodAnswers": 0,
      "BadAnswers": 1,
      "WasLastAnswerGood": false
    },
    {
      "Language": "Language2",
      "Translation": "village",
      "GoodAnswers": 1,
      "BadAnswers": 0,
      "WasLastAnswerGood": true
    }
  ]
}

Klasa, której obiekty chcemy wrzucić do Raven DB może być zwykłym POCO z dokładnością do jednej rzeczy. Musi posiadać taką właściwość:

public int Id { get; set; }

To przykład konwencji. Jeśli chcemy zmienić sposób przechowywania identyfikatora, należy skorzystać z DocumentStore.Conventions.FindIdentityProperty. Użyty przeze mnie EmbeddableDocumentStore dziedziczy z DocumentStore, a więc jeśli znudzi mi się Id to zawsze mogę to zmienić.

Jeśli chcemy aby Raven DB ignorował niektóre właściwości w czasie zapisywania obiektu to powinniśmy oznaczyć je atrybutem Newtonsoft.Json.JsonIgnore, który działa w taki sam sposób jak XmlIgnore dla XmlSerializer.

Zapisz/Zmień

Operację wstawienia nowego dokumentu do bazy lub aktualizacji już istniejącego wykonuję w taki sam prosty sposób np.:

public void Save(ExpressionEntity ex)
{
 using (var session = Store.OpenSession())
 {
  session.Store(ex);
  session.SaveChanges();
 }
}

Zaczynam, więc od otworzenia sesji pracy z RavenDB. Następnie przy pomocy metody Store wrzucam do bazy nowy dokument lub aktualizuję już istniejący. Jak widać nie przejmuję się, którą operację właściwie wykonuję. Jeśli obiekt będzie miał pusty/zerowy Id to zostanie utworzony nowy dokument, a właściwość Id zostanie uaktualniona. Jeśli Id zostanie wypełnione Raven DB spróbuje odszukać istniejący dokument i go uaktualnić. Jeśli nie znajdzie dokumentu o podanym identyfikatorze utworzy go. Metoda SaveChanges to coś w rodzaju Commit'a: wysyła zmiany do serwera.

Usuń

Usuwanie dokumentów z bazy również jest bardzo proste np.:

public void Remove(ExpressionEntity ex)
{
 using (var session = Store.OpenSession())
 {
  session.Delete<ExpressionEntity>(session.Load<ExpressionEntity>(ex.Id));
  session.SaveChanges();
 }
}

Jak widać przed usunięciem ładuję obiekt z bazy na podstawie identyfikatora. Jest to potrzebne ponieważ inaczej dostaniemy błąd z informacją, że obiekt nie jest doczepiony do sesji (is not associated with the session, cannot delete unknown entity instance). Nie znalazłem innego sposobu rozwiązania problemu.

Ważna uwaga

Powyżej przedstawiłem dwie przykładowe metody Save oraz Remove, które odpowiednio tworzą/aktualizują jeden dokument oraz usuwają jeden dokument z bazy danych. W przypadku wykonywania operacji na wielu dokumentach takie podejście będzie zbyt kosztowne. Jeśli zachodzi potrzeba pracy z wieloma dokumentami to powinniśmy zrezygnować z takiego mikro zarządzania i jak najwięcej operacji wykonywać w ramach jednej sesji.

Podsumowanie

Dzisiaj pokazałem jak wykonywać podstawowe operacje na dokumentach. Jak widać jest to bardzo proste. Właściwie nie musimy nic robić aby nakłonić nasze obiekty do współpracy z Raven DB. Nie potrzebujemy również mappera relacyjno-obiektowego. To jest właśnie to co bardzo mi się spodobało w Raven DB.

Definiuję sobie klasę, tworzę jej instancje i po prostu wrzucam je do bazy danych. Nie piszę komend INSERT, UPDATE lub DELETE. Nie instaluję dodatkowych komponentów. Nie konfiguruję mapowań pomiędzy tabelami i obiektami. Nie definiuję schematu bazy danych. Jest prosto, szybko i przyjemnie czyli tak jak powinno być!

Na koniec znowu podsumujmy co już mamy/umiemy:

• Bazę Raven DB osadzoną w aplikacji hostującej.
• Kod inicjalizujący Raven DB.
• Dostęp do Raven Studio i API REST'owego.
• Obiekty POCO jakie mogą zostać umieszczone w Raven DB.
• Kod dodający/zmieniający/usuwający dokumenty.

RavenDB (cz. 1)

Home

Raven DB to dokumentowa baza danych, przedstawiciel trendu NoSQL, opracowana przez Ayende i jego zespół. Całkiem niedawno bo w październiku 2011 Ayende był zresztą w Polsce i opowiadał o swoim dziecku. Kilka miesięcy temu w jednym ze swoich pet project postanowiłem zmienić technologię dostępu do danych i wybór padł właśnie na Raven DB.

Kilka słów wstępu

Projekt ten to program LanguageTrainer wspomagający naukę słówek. Pomysł jego napisania narodził się ponad rok temu kiedy "ponownie" rozpocząłem naukę języka niemieckiego. W sieci nie znalazłem programu, który spełniałby moje oczekiwania. Zdecydowałem więc, że napiszę coś szytego na miarę. Początkowo rozpoczęło się niewinnie: listę słówek i ich tłumaczeń trzymałem w pliku. Dokładniej mówiąc był to po prostu wynik serializacji XML'owej. Podejście to przestało się sprawdzać kiedy do głowy zaczęły mi przychodzić kolejne pomysły: A może dodać bardziej zaawansowane wyszukiwanie, jakieś statystyki itd.

Początkowo pomyślałem o przejściu na bazę relacyjną, ale stwierdziłem, że tutaj nie nauczę się niczego nowego. Pomyślałem, że fajnie będzie wypróbować coś zupełnie nowego, z czym nie miałem jeszcze do czynienia, a ponieważ wcześniej czytałem trochę o Raven DB i wiedziałem, że ma .NET'owe API, wybrałem właśnie ją.

Z bazą tą już trochę pracuję, z braku czasu niezbyt intensywnie, ale zebrałem już trochę doświadczeń i postanowiłem sie nimi podzielić. Planuję serię postów, w których opiszę jak pracuje się z Raven DB na przykładzie swojego pet project. Nie będzie to jednak typowy tutorial omawiający wszystkie zagadnienia. Poruszę tylko te, z którymi miałem okazję się zapoznać.

Zaczynamy

LanguageTrainer to typowa aplikacja grubego klienta (WPF + MVVM). Nie chciałem jednak uzależniać się od połączenia z serwerem. Dlatego zdecydowałem się na hostowanie Raven DB w procesie aplikacji. Po ściągnięciu paczki z binariami na swoje potrzeby skopiowałem więc katalog EmbeddedClient. W tym momencie zaznaczę jeszcze, że warstwę dostępu do danych mam ukrytą za dobrze zdefiniowanym interfejsem, a więc aplikacja nie wie z jakim źródłem danych pracuje. Poniżej fragment kodu z klasy implementującej ten interfejs, odpowiedzialny za zainicjowanie Raven DB.

public EmbeddableDocumentStore Store { get; private set; }

...

public void Init(string dir)
{
 Store = new EmbeddableDocumentStore
 {
  DataDirectory = dir,
  UseEmbeddedHttpServer = true,
 };

 Store.Initialize();
}
 

Instancja EmbeddableDocumentStore posłuży nam później do otwierania sesji pracy z Raven DB, wykonywania zapytań itd. W kodzie tym ustawiam tylko dwie właściwości. DataDirectory wskazuje katalog roboczy, w którym Raven DB utworzy odpowiednią strukturę katalogów i gdzie będzie trzymał dane. Za pierwszym razem inicjalizacja zajmie więc trochę więcej czasu.

Istotna jest też właściwość UseEmbeddedHttpServer. Dzięki ustawieniu jej na true mam dostęp do napisanej w Silverlight aplikacji Raven Studio do zarządzania dokumentami oraz, co mniej ważne z mojej perspektywy, dostęp REST'owy do dokumentów. Oczywiście ponieważ Raven DB jest hostowany przez mój program, aplikacja Raven Studio będzie dostępna tylko wtedy, kiedy uruchomiony jest LanguageTrainer.

Numer portu z jakiego będzie korzystał serwer HTTP ustawiamy w pliku konfiguracyjnym aplikacji dodając następujący wpis:

<appSettings>
    <add key="Raven/Port" value="8888" />
</appSettings>

To jednak nie wszystko. Jeśli w tym momencie spróbujemy uruchomić Raven Studio otrzymamy od serwera HTTP taki błąd:

Could not find file Raven.Studio.xap, which contains the Raven DB Studio functionality. Please copy the Raven.Studio.xap file to the base directory of RavenDB and try again.

Plik Raven.Studio.xap znajdziemy w dystrybucji Raven DB i musimy umieścić go w katalogu z jakiego uruchamiamy aplikację. Ja zrobiłem to w ten sposób, że dodałem go do projektu, Build Action ustawiłem na Content, a Copy to Output Directory na Copy if newer. Testowałem w przeglądarkach Chrome, Firefox oraz IE i działa.

Podsumowanie

Tyle na dzisiaj. Podsumujmy co już mamy/umiemy:

• Bazę Raven DB osadzoną w aplikacji hostującej.
• Kod inicjalizujący Raven DB.
• Dostęp do Raven Studio i API REST'owego.

W następnej części opiszę jak wykonywać podstawowe operacji na dokumentach.

OciEnvCreate failed with return code -1

Home

OciEnvCreate failed with return code -1 to błąd na temat, którego można znaleźć w sieci sporo pytań ale mało odpowiedzi. Ja niestety miałem tego pecha i również na niego trafiłem, a w rezultacie straciłem kilka dobrych godzin. Błąd ten może pojawić się przy próbie nawiązania połączenia z bazą danych Oracle. Z informacji jakie znalazłem wynika, że najczęściej pojawia się w trzech przypadkach:

• Brak zainstalowanych bibliotek klienckich Oracle.
• Zła wersja zainstalowanych bibliotek klienckich Oracle.
• Brak uprawnień użytkownika na jakim uruchomiony jest proces roboczy ASP.NET do katalogu z bibliotekami klienckimi Oracle.

Co do dwóch pierwszych scenariuszy to ani nie zaprzeczę i ani nie potwierdzę ponieważ na maszynie, na której napotkałem problem działał już program łączący się z bazą danych Oracle. W moim przypadku błąd pojawił się w usłudze webowej zainstalowanej na IIS'ie. Początkowo myślałem, że chodzi o coś zupełnie innego ponieważ tylko pierwsze odwołanie do wspomnianej usługi kończyło się błędem. Przy każdym następnym odwołaniu Web Service zachowywał się tak jakby działał tylko, że zwracał niepoprawne wyniki. No cóż pewnie ktoś gasił wyjątek! Przy pierwszym odwołaniu do usługi wołana jest natomiast metoda Application_Start zdefiniowana w pliku Global.asax, która w tym przypadku zawierała kod nawiązujący połączenie z bazą danych.

Kiedy już odkryłem pierwotną przyczynę niepoprawnego działania usługi postąpiłem zgodnie ze znalezioną sugestią i nadałem pełne uprawnienia do katalogów z bibliotekami Oracle, wstępnie użytkownikowi Wszyscy. Jednym z tych katalogów był C:\app\Administrator\product\11.1.0\client_1.

Następnie zrestartowałem pulę aplikacji do jakiej została przypisana usługa i sprawdziłem czy to coś zmieniło. Okazało się, że niestety nie. Spróbowałem jeszcze raz i nic. Po jakimś czasie stwierdziłem, że może chodzi o jakieś inne katalogi i zdesperowany nadałem użytkownikowi Wszyscy uprawnienia do całego dysku. Niestety znowu bez sukcesu. W tym momencie przyszło mi do głowy, że może nie wystarczy nadanie uprawnień i zrestartowanie puli aplikacji tylko trzeba dodatkowo uruchomić ponownie komputer, co też zrobiłem. Okazało się to strzałem w dziesiątkę.

Zadowolony z sukcesu postanowiłem tym razem zrobić wszystko po bożemu czyli cofnąć nadanie uprawnień wszystkim do wszystkiego i nadać pełne uprawnienia tylko jednemu użytkownikowi i tylko do jednego folderu, ewentualnie dwóch ale ściśle określonych. Na początek chciałem się jednak upewnić o jaki konkretnie folder chodzi i jakiego użytkownika. Postanowiłem więc wrócić do stanu początkowego kiedy błąd jeszcze występował. Jakie było jednak moje zdziwienie kiedy okazało się, że jest to niemożliwe ponieważ po cofnięciu nadania uprawnień i restarcie maszyny wszystko działa.

Reasumując niestety ale nie potrafię z 100% pewnością stwierdzić komu, do czego i jakie uprawnienia należy nadać. Faktem jest jednak, że instalator Oracle nie do końca poprawnie konfiguruje system w czasie instalacji. Faktem jest również, że nadanie prawdopodobnie pełnych uprawnień, prawdopodobnie do folderów wymienionych powyżej, prawdopodobnie dla użytkownika na jakim działa proces roboczy ASP.NET i prawdopodobnie restart komputera pomaga. Mam nadzieję, że te prawdopodobne stwierdzenie oszczędzi komuś kilka godzin pracy.

Enterprise Library, Informix i CLOB

Home

Data Access Application Block to część Enterprise Library oparta o ADO.NET odpowiedzialna za komunikację z bazą danych. Jedną z bardzo miłych cech tego modułu jest to, że w dużym stopniu ukrywa przed programistą rodzaj bazy danych z jakim pracuje. Uprasza to pisanie aplikacji kompatybilnych z wieloma bazami danych.

Oczywiście nie wszystko jest takie różowe o czym przekonałem się ostatnio. W tej chwili pracuję głównie z bazą danych Informix firmy IBM i Data Access Application Block radził sobie z nią całkiem dobrze ale do czasu kiedy postanowiłem wykorzystać typ bazodanowy CLOB służący do przechowywania dużych obiektów znakowych.

Nie wnikając w szczegóły zapis danych do kolumny o typie CLOB nie udał mi się w ogóle, a odczyt częściowo :) Częściowo ponieważ mogłem odczytać tylko fragment danych. Nie wykluczam możliwości, że mogłem popełnić jakiś błąd ale nie chcąc tracić czasu problem rozwiązałem wykorzystując sterownik ADO.NET firmy IBM przeznaczony tylko do obsługi Informix'a. Biblioteka ze sterownikiem nazywa sie IBM.Data.Informix.dll i instalowana jest razem z Client SDK. U mnie znajdowała się w lokalizacji C:\Program Files (x86)\Informix\Client-SDK\bin\netf20. Model pracy z klasami z tej biblioteki jest prawie taki sam jak z standardowymi klasami ADO.NET. Mamy więc klasę IfxCommand, która dziedziczy z DbCommand, IfxConnecton, która implementuje interfejs IDbConnection itd. Różnice są niewielkie i dotyczą rzeczy specyficznych dla Informix'a czyli np.: obsługi typu CLOB.

Wykorzystanie biblioteki rozwiązało oczywiście mój problem. Sądzę, że wybór IBM.Data.Informix.dll jest dobrym pomysłem dla każdego kto ma zamiar pracować z bazą danych firmy IBM. Nie ma jednak róży bez kolców. Użycie rozwiązania właściwego dla konkretnej bazy danych zamiast Enterprise Library wpływa negatywnie na przenoszalność aplikacji, a własciwie ją uniemożliwia. Oczywiście klasy specyficzne dla Informix'a można odpowiednio przykryć tak aby ewentualna podmiana była łatwiejsza ale nie jest to równoznaczne z użyciem Data Access Application Block.

Reasumując jeśli chcę zachować przenaszalnośc aplikacji będę musiał zastanowić się jak dostosować tą bibliotekę do współpracy z Enterprise Library.

"Decimal byte array constructor requires an array of length four containing valid decimal bytes"

Home

"Decimal byte array constructor requires an array of length four containing valid decimal bytes"

Z takim błędem spotkałem się ostatnio pisząc kod komunikujący się z bazą danych. Niestety ale błąd ten miał również dwie utrudniające jego poprawienie właściwości. Po pierwsze pojawiał się na kilku komputerach ale nie na moim. No cóż syndrom "a u mnie działa" zdarza się każdemu. Po drugie kod w jakim występował zdawał się wyglądać całkowicie niewinnie:

DataSet ds = New DataSet

OleDbDataAdapter adapter = New OleDbDataAdapter
adapter.SelectCommand = New OleDbCommand(Command, Connection)

adapter.Fill(ds)

Dokładniej mówiąc wyjątek pojawiał sie przy wywołaniu metody Fill. Kiedy zapytałem wyszukiwarkę o treść komunikatu znalazłem kilkanaście forów z pytaniami dotyczącymi tego błędy w kontekście komunikacji z różnymi bazami danych (ja używam bazy danych Informix). Niestety prawie wszystkie zadane pytania zostały bez odpowiedzi. Znalazłem jednak wypowiedź sugerującą, że błąd pojawia się jeśli w zapytaniu użyto funkcji agregujących.

Zapytanie, którego ja użyłem zawierało całkiem sporo przykładów użycia funkcji agregujących, postanowiłem więc usunąć je z zapytania i zobaczyć co się stanie. W wyniku modyfikacji zapytania wyjątek nie pojawił się. Miałem więc już jakąś wskazówkę co robić dalej. W następnym kroku dodawałem do zapytania kolejne odwołania do funkcji agregujących żeby zobaczyć, które dokładnie spowoduje błąd.

Po kilku próbach znalazłem kłopotliwy fragment zapytania. Wyglądał on tak:

SELECT ..., SUM(Col1) - Sum(Col2), ... 

W tym momencie przypomniałem sobie pewną rzecz i już wiedziałem jak rozwiązać problem. Tak jak napisałem wcześniej błąd nie pojawiał się na komputerze, na którym pracowałem. Dane, które pobrałem z bazy danych mogłem, więc wyświetlić na kontrolce gridowej. Kiedy zrobiłem to po raz pierwszy zauważyłem, że w niektórych kolumnach liczby prezentowane są z bardzo dużą precyzję pomimo, że na poziomie bazy danych użyto typu DECIMAL o precyzji 2. Problem rozwiązałem wymuszając po prostu odpowiednie formatowanie. Teraz jednak okazało się, że kolumny o "dziwnym" formatowaniu na mojej maszynie pokrywały się z przykładami użycia funckji, które powodowały błąd na innych stacjach.

Pierwszy wniosek jest taki, że wynik operacji arytmetycznych na rezultatach działania funkcji agregujących może mieć wyższą precyzję niż by to wynikało z typu kolumn. W przypadku niektórych działań arytmetycznych ma to oczywiście sens, chociaż nie w przypadku odejmowania czy dodawania. Ale mniejsza o tym. Istotne jest to, że z powodu zwiększonej precyzji nie jest potem możliwe skonstruowanie wartości typu decimal i generowany jest wyjątek. Rozwiązanie jest proste. Trzeba zaokrąglić wynik:

SELECT ..., ROUND(SUM(COl1) - Sum(Col2), 2), ... 

Z tego co się dowiedziałem pomóc może również użycie nowszych sterowników OLEDB. Z drugiej strony na moim komputerze zainstalowana jest taka sama wersja sterowników jak na innych. Różnica jest taka, że ja używam Windows 7 ale trudno powiedzieć czy to ma jakiś wpływ. W każdym razie pytanie czemu błąd nie pojawia się na wszystkich stacjach pozostaje otwarte.

ADO.NET Data Services, Jak to ugryźć?

Home

Wszystkich zainteresowanych rozpoczęciem zabawy z technologią Microsoft'u ADO.NET Data Services (nazwa kodowa Astoria) chciałbym zachęcić do zapoznania się z serią filmików spod znaku How Do I:

• Getting Started with ADO.NET Data Services over a Relational Database
• Getting Started with ADO.NET Data Services over a Non-Relational Data Source
• Consuming an ADO.NET Data Service in a Silverlight Application
• Consume an ADO.NET Data Service in a .NET Application

Astoria umożliwia naprawdę łatwy i szybki sposób udostępniania danych z różnych źródeł w sieci (w szczególności może to być oczywiście baza relacyjna). Dostęp do danych został zorganizowany zgodnie z podejściem typu REST czyli upraszczając aby uzyskać dostęp do zasobu musimy znać jego URI. Każdy z filmików pokazuje krok po kroku jak coś zrobić przy pomocy ADO.NET Data Services. Obejrzenie każdego z nich zajmie wam kilkanaście minut (oczywiście trzeba znać język angielski). Bardziej dogłębne (i znacznie dłuższe) wprowadzenie znajdziemy tutaj Developing Applications Using Data Services. Aby rozpocząć używanie Astorii potrzebujemy Visual Studio 2008 z Service Pack 1. Wersję Express już z Service Pack 1 znajdziemy tutaj.