Strona główna > Java > Pisanie procedur składowanych w hibernate

Pisanie procedur składowanych w hibernate

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.

Kategorie:Java Tags: , , ,
  1. Brak komentarzy.
  1. No trackbacks yet.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

%d bloggers like this: