Archiwum

Posts Tagged ‘oracle’

Pisanie procedur składowanych w hibernate

20/01/2012 Dodaj komentarz

Taka koncepcja urodziła mi się dziś: pisanie procedur składowanych w JPA – tutaj zawężam do implementacji Hibernate, a z baza można wskazać Oracle, ale to bez znaczenia.
Nie chodzi o wywoływanie procedur składowanych poprzez JPA czy zwykłe JDBC. Nie chodzi tu także o pisanie w javie ciała procedury składowanej (co na Oraclu da się).
To o co mi chodzi to wprowadzenia pewnej magicznej transformacji, która z kodu javy operującym na encjach JPA wygeneruje odpowiedni kod procedury (w tym wypadku PL/SQL) i stworzy taki kod na bazie. Na javie mogłoby wyglądać to tak:

	@AsStoredProcedure
	public void addCats(Long ownerId, Date date){
		List<Cat> cats = em.createQuery(
		    "select cat from Cat as cat where cat.birthdate < ?1")
		    .setParameter(1, date, TemporalType.DATE)
		    .getResultList();
		Owner owner em.find(Owner.class, ownerId);
		owner.getCats().addAll(cats);
	}

Stojąca za tym idea mogłaby być taka: jeśli wskazana metoda (tutaj oznaczoną odpowiednią adnotacją) może być prze-konwertować poprawnie na odpowiedni ciąg instrukcji PL/SQL, to zebrać to w jedną procedurę składowaną i stworzyć takie coś na bazie. Następnie w miejsce samej metody wstawić odpowiednie proxy, które to będzie wołane zamiast oryginalnej procedury.

Za i przeciw
Dlaczego tak się bawić?
Główna kwestia to wydajność. Stosowanie JPA często i tak kończyło się na wybiegach w postaci procedur składowanych dla poprawienia wydajności. To jednak wprowadzało rozbicie kodu na dwa miejsca, o które trzeba dbać i uaktualniać wraz ze zmianami.
Oczywiści można z tym żyć. Jeśli nałoży się odpowiedni reżim dbania o kod, większość błędów się nie prześliźnie. Jednak ze swojego doświadczenia widzę że jeśli jakiś kod można prosto napisać w JPA to się tak robi. Łatwiej jest to zrobić niż stworzyć analogiczną procedurę na bazie (w końcu programujemy w javie, a nie w sql :)), a to nie zawsze prowadzi do wydajnego kodu (zwłaszcza kiedy realizuję on scenariusz: wyciągnięcia wielkiej kolekcji danych, prostych zmian na jej elementach, podłączenie wszystkiego do innej encji i na koniec utrwalenie całości).
Dlatego też zamarzyło mi się właśnie coś takiego, co sprawiłoby że pisanie prostych procedur byłoby przezroczyste.

Wadą tu jest wprowadzenie dodatkowej abstrakcji (ktoś w debugu mógłby się zastanawiać dlaczego ten kod się nie wykonuję), ale to można by załatwić wprowadzając przemyślane API.

Sposoby realizacji
Realizacja tego jest możliwa, w końcu w logach widać sql który jest faktycznie wykonywany. Więc wystarczy go wziąć, trochę sparsować, opakować w kod tworzący procedurę, zarejestrować to na bazię, i wygenerować odpowiedni zamiennik w postaci proxy, który to będzie wołany zamiast metody w javie.
Najbardziej problematyczne może być pisanie w kodzie tak aby było to zamieniane na odpowiedni kod, pewnie nie każde wyrażenie z PL/SLQ może być zrealizowane.

Co do wgrywania procedur składowanych to jest taki mechanizm opis tutaj, poprzez zwykłe executeUpdate.

Reklamy
Kategorie:Java Tagi: , , ,

Błędy związane z czasem

20/03/2011 Dodaj komentarz

Nazbierało mi się ostatnio trochę ciekawych przypadków/błędów związanych z czasem. Są one trochę inne niż te które zazwyczaj spotykam. Mają one tą szczególną cechę że pojawiają się naglę, mimo że nic się w strukturze kodu nie zmieniło; lub występują, a potem znikają (duch).
Przytoczone tu przypadki są związane z bazą danych (może lista się rozszerzy z czasem, a może ktoś podrzuci inne przykłady). Są to błędy związane raczej z danymi, stąd może dlatego częściej pojawiają się właśnie przy bazie.

Przypadek przeterminowania się danych
Objawy: Coś nagle przestało działać, a nic nie było ruszane.
Przykład: Sprawdzenie czy dziś nie mija jakaś data. Warunek ten może być zaszyty w jakimś zapytaniu, widoku czy procedurze. Wszystko jest dobrze na początku, gdy owa graniczna data jest odległa w czasie, powiedzmy za rok. Kiedy jednak to nadchodzi, może być zdziwienie, chwila zamieszania i długotrwałe przeszukiwanie całego kodu, a baza często stoi jako jeden z ostatnich etapów tego szukania.
Nie chodzi tu tylko o przypadek zaszycia sprawdzenia czasu z obecną data (SYSDATE), ale może to być jakaś wartość wzięta z bazy, którą ktoś nieopacznie zmienił, a związek z błędem może nie być łatwo dostrzegalny.

Przypadek niewłaściwego formatu czasu
Objawy: Brak działania funkcjonalności w określonych porach.
Przykład: Narzucenie dostępności czegoś w określonych dniach, czy godzinach.
Błędy gdy zegar systemowy rozjedzie się z rzeczywistością. Bardziej prawdopodobne na etapie developmentu – kiedy nie dba się zbytnio o środowisko i nikomu nie przeszkadza że zegar spieszy się przykładowo o 2 godziny.
Określenie dnia tygodnia (ten właśnie przypadek natchną mnie do napisania tego posta 😉 ). Nie właściwa instalacja bazy i przyjęcie formatu daty, lokalizacji serwera w innej strefie czasowej. A to może prowadzić, że na jednej instancji bazy funkcja może zwracać inne wartości niż na drugiej. Ów przykład dla Oracla
TO_CHAR (SYSDATE, 'D')
określenia jaki dzień tygodnia mam – raz może się to liczyć od niedzieli, innym razem od poniedziałku.

Kategorie:Inne Tagi: ,

Poszukiwanie narzedzia

17/10/2010 Dodaj komentarz

Na początku była potrzeba tworzenia dokumentacji, zostało to opisane tutaj. Miało to jednak dalszą kontynuacje.

Wraz z przejściem do projektu (trwał on już od jakiegoś czasu) stanąłem przed wyzwaniem zapoznania się z bazą danych (jedną z wielu). Dokładniej miałem do rozpoznania jej wycinek, aby przygotować kilka zapytania. I tu okazało się, że to co kiedyś stworzyłem w innym projekcie na potrzeby klienta/administratora może być teraz pomocne dla mnie. Było to sposób produkcji dokumentu przedstawiającego relacje pomiędzy tabelami w bazie. W zamierzeniu miała to być pomoc do zaznajomienia się z baza, w sam raz na początek, gdy obraz jej nie jest jeszcze utrwalony w głowie. Czytaj dalej…

Kategorie:Inne Tagi: , , ,

Dokumentacja struktury bazy

25/08/2010 Dodaj komentarz

Trochę o generowaniu dokumentacji, czyli dobrze kiedy znaczną jej cześć można właśnie wygenerować.
Miałem za zadanie stworzyć dokumentacje struktury bazy dla klienta. Mogłem zakasać rękawy i mozolnie pokrótce opisać każdą z tabel oraz jej powiązania z innymi tabelami (dokument głównie to miało zawierać). Całość przy około 250 tabelach mogło mi zająć około 3 dni :). Ponieważ nie było to naglące i miałem trochę luzu postanowiłem poszukać sposobów na automatyzacje tego. Ostatecznie zajęło mi to ponad 5 dni 😉 (ale nie w całości poświęconych temu), no ale dzięki temu wykonanie ewentualnej aktualizacji jest teraz o wiele szybsze. Czytaj dalej…