W poprzednim wpisie zmieniłem system zarządzania zależnościami z Nugeta na Paket. Ściąganie paczek Nugetowych skonwertowało się automatycznie za pomocą dołączonego narzędzia, teraz pora dodać główny cel tych zabiegów - archiwum z przenośną (samowystarczalną) wersją Neo4j.
Jest ona dostępna pod poniższym adresem i trochę waży:
$ wget http://neo4j.com/artifact.php?name=neo4j-community-3.0.1-windows.zip
...
Length: 62661995 (60M) [application/zip]
Aby dodać taką zależność musimy ją dodać do pliku packet.dependencies:
$ more paket.dependencies
source https://www.myget.org/F/roslyn-nightly/
source https://www.myget.org/F/dotnet-core
source https://www.nuget.org/api/v2/
framework >= net45
nuget FsXaml.Wpf 0.9.9
nuget Microsoft.Diagnostics.Runtime 0.8.31-beta
http http://neo4j.com/artifact.php?name=neo4j-community-3.0.1-windows.zip
Więcej...
Tak jak pisałem w jednym z poprzednich postów, zdecydowałem się użyć Paket do zarządzania zależnościami w projekcie. Dlaczego? Ponieważ poza zależnościami NuGetowymi, mam jedną dużą, niestandardową - standalone binarki bazy neo4j. Tak jak pisałem, Paket poza źródłami z serwerów NuGetowych potrafi korzystać ze źródeł Gita oraz po prostu zasobów dostępnych przez HTTP. Ostatnio trochę oszukałem, mówiąc, że neo4j jest dostępny w samowystarczalnym pliku ZIP pod adresem http://neo4j.com/download-thanks/?edition=community&flavour=winzip. Stronka ta jedynie rozpozczyna auto-download pliku pod adresem http://neo4j.com/artifact.php?name=neo4j-community-3.0.1-windows.zip i to ten plik będę musiał wskazać jako zależność HTTP.
Ten wpis opisuje natomiast sposób konwersji klasycznej solucji opartej o Nugety (i plik packages.config) do wersji używającej Paketa. Więcej...
Jak już nie raz wspominałem, chciałbym by sercem MemoryVisualizera był język zapytań oparty o Cypher, a właściwie leżąca pod spodem baza grafowa Neo4j. Ma mi to zapewnić dużą ekspresyjność zapytań oraz (mam nadzieję) dużą szybkość działania. Tutaj pojawia się pewien drobny temat do przemyślenia. Neo4j napisany jest w Javie i szczęściarze piszący w tym języku mogą załączyć ten silnik jako część swojej aplikacji. Niestety w aplikacji .NETowej o takim self-hostowaniu nie może być mowy. Portu Neo4j na .NET nie ma, choć pojawiły się i takie pomysły, np. w formie Neo4Net. Ciekawa dyskusja na ten temat odbyła się na grupie lists.neo4j.org. Więcej...
Memory Visualizer wymaga udostępnienia języka zapytań odnośnie obiektów i struktur w pamięci. Jak pisałem w części Cypher, co to jest?! , język ten nazywam MQL - Memory Query Language. W istocie jest to jednak po prostu Cypher, który rozszerzę o elementy kontrolujące sposób wyświetlania.
Aby sobie przypomnieć, co chcę osiągnąć, wróćmy do przykładowego rysunku z opisu projektu:
Więcej...
Obiekty w pamięci tworzą całkiem rozbudowany graf. Mają pomiędzy sobą referencje, są też poukładane w segmenty w ramach pamięci procesu, które to możemy potraktować również jako kolejny węzeł w grafie. W tym sensie segment może być rodzicem wielu obiektów, które zawiera itd. W każdym bądź razie, tak jak już było obiecane, pora zastanowić się nad językiem zapytań do owych grafów. Choć padały inne propozycje (m.in. użycie SPARQL), ja jednak pozostaję pod nieustającym wrażeniem prostoty i przejrzystości języka Cypher, używanego w grafowej bazie danych Neo4j. Więcej...