Custom SimpleData.PostgreSql

O Simple.Data parokrotnie już pisałem na blogu. W aktualnym projekcie używamy tej biblioteki dość intensywnie – tak naprawdę zastąpiliśmy nią całkowicie NHibernate i jest to nasz jedyny sposób na kontakt z bazą. W większości scenariuszy w tym systemie ów wybór sprawdził się znakomicie. Ma to także swoje wady, ale o tym może kiedy indziej.

Problem pojawia się w momencie, gdy chcemy wykorzystać Simple.Data z bazą danych, która nie jest “oficjalnie” wspierana przez autora – Marka Rendle. My używamy PostgreSql, a adapter do tej bazy był nieco… przestarzały. Na tyle przestarzały, że nie dało się go używać, ponieważ został skompilowany z baaardzo dawną wersją Simple.Data, zawierającą sporo irytujących bugów (jak na przykład zwracanie 0 zamiast null dla int?, nawet jeśli w bazie null siedzi).

Postanowiliśmy zainwestować kilka godzin i spróbować zaktualizować ten adapter. Okazało się to dość proste, a efekt można zobaczyć na ultrikowym githubie: https://github.com/ultrico/Simple.Data.PostgreSql/.

Tak naprawdę początkowo jedyne co mieliśmy do zrobienia to zmiana sygnatury dwóch metod, które zmieniły się w publicznym API Simple.Data pomiędzy wersją 0.16.2.2 a 0.18.3.1.

Z czasem prawdopodobnie natkniemy się na inne “issues”, z którymi, z racji przejęcia kodu, będziemy mogli własnymi siłami powalczyć.

Na pierwszy ogień poszło wsparcie dla enumów. Poprzedni adapter wywalał się w momencie insertu do bazy obiektu z właściwością enum, co prowadziło do dość brzydkich “workarounds”: dodawania do klasy właściwości typu int mapowanej do kolumny w bazie i enumowych gettera/settera do ustawiania tego w kodzie. Gdy drugi raz przyszło takie coś pisać, nastąpił moment “kiedy powiem sobie dość”. Okazało się, że fix zajął raptem niecałą godzinę i w naszej wersji adaptera można wrzucić do PostgreSql enuma za pomocą Simple.Data – zarówno przy wstawianiu jednego, jak i wielu obiektów (bo błąd występował w obu przypadkach).

Na ogień drugi – stronicowanie. Wygląda na to, że oryginalny autor przerabiał po prostu adapter do MySql, bo Skip().Take() generowało instrukcję LIMIT x,y, co w Postgre jest oczywiście niepoprawne – tutaj trzeba użyć składni LIMIT x OFFSET y. Co ciekawe, przy uruchomieniu testów wszystko przechodzi… bo test sprawdzający poprawność stronicowania został opatrzony atrybutem: [Ignore(“Skip does not appear to be working”)]. Nie-nice. Tak czy siak – poprawione.

Prawdopodobnie problemów tej natury będzie w przyszłości więcej i, równie prawdopodobnie, będziemy się z nimi w miarę upływu czasu rozprawiać. Jeśli zatem trzymasz dane w PostgreSql i chcesz nałożyć na to Simple.Data, zachęcam do obserwowania projektu…. a najlepiej do aktywnego udziału w jego rozwoju. Nie ma go na żadnym nugecie, więc jedyny sposób to clone/fork i kompilacja rękami własnymi.