blogowania ciąg dalszy - hibernate tips&tricks

Od daaaawna nie było żadnego posta (od lipca zeszłego roku ;]). Nie będę się na ten temat zbytnio rozpisywał bo tematem bloga w końcu nie jest "Dlaczego regularnie zarzucam blogowanie?", a przyczyna jest prozaiczna - brak czasu. Ponieważ jednak różne przemyślenia w głowie już mi się kotłują, a ciekawych linków na sieci coraz więcej postanowiłem, że od dziś będę starał się wrzucać posty regularniejsze a krótsze (dosłownie 2 zdania jeśli nie będę miał czasu na więcej). Ponieważ szcerze mowiąc sciągnąłem ten pomysł z bloga Stefana Tilkova nie mam zamiaru się go wstydzić :)

Do rzeczy - czyli Hibernate tips and tricks:

1) Strategie nazewnictwa "bytów" w bazie danych
Jeśli w projekcie każde pole (tudzież setter) opakowane jest kupą adnotacji z tym jak nazywać poszczególne elementy w bazie danych (skądinąd przygotowane takiego standardu w zakresie projektu to bardzo dobry pomysł) być może przyszedł czas zcentraliować te informację. Hibernate przychodzi nam z pomocą i dostarcza możliwość określenia strategii jak poszczególne elementy po-naszemu nazywać :)
Tip: Warto dodać strategię nie tylko do aplikacji ale (i to zwłaszcza) do ant'owego taska generującego schemat :)

2) Filtrowanie kolekcji po stronie bazy danych
Nie raz zdarzyło mi się znaleźć kawałki kodu przepuszczające kolekcje przez jakąś logikę (mniej lub bardziej biznesową) które albo:
- zamiast wykorzystać istniejącą asocjację kolekcji po prostu zbierały te informację z bazy danych, dodając do zapytania warunek 'WHERE'.
albo
- zbierały z bazy całą kolekcję (na ogół przez lazy fetch, czyli po prostu wywołanie gettera) po czym sobie po niej radośnie iterowały szukając odpowiednich danych.
Tymczasem Hibernate pozwala na przefiltrowanie kolekcji (oraz tablic) do których dostęp mamy po stronie Javy za pomocą mechanizmu filtrów. Już nie musimy wybierać między szybkością (HQL i baza danych) oraz czytelnością (zrobić to po stronie Javy).

3) Nazywanie kolumny a nazwy zabronione
Jeśli tylko korzystasz z PostgreSQL pewno nie raz już ucieszył Cię error "wszystko wybucha wywołaj getNextException() żeby odkryć gdzie" (skądinąd takie połykanie Exceptionów przyprawia mnie o lekki ból głowy) tylko po to by dowiedzieć się że Twoja klasa User (chyba User.. o ile pamiętam że właśnie ten wybuch zaliczyłem na PostgreSQL :]) niestety tak się nazywać nie może :) Jeśli nie chcesz użyć nazw typu: Ape, Non_Geek dla swoich klientów polecam zapoznanie się z lekturą.