Zapytania na bazie danych:
JPQL - specyfikacja JPA definiujaca jezyk zapytan, ktora jest mieszanka SQL i obiektow
- Jakarta Persistance Query Language
- jezyk bardzo podobny do sql ale bedziemy operowali na obiektach
- HQL - Hibernate Query Language - podzbior JPQL
- wada HQL jest to ze jest podobny do SQL i ludzie czesto myla go z SQL
- HQL ma wlasna gramatyke w postaci Stringa
- HQL nie sluzy do modyfikacji bazy danych, sluzy tylko do CRUDow
- sa tlumaczone przez Hibernate to tradycyjnych SQLek
- HQL pracuje na podstawie klas i ich wlasciwosci a nie na podstawie tabel i kolumn jak SQL
Criteria API -
Native Query
Stored Procedures
DTO - Data Transfer objects
- ograniczenie ilosci wynikow zapytania
- pomaga w grupowaniu zapytan hql w jednym miejscu
- w efekcie mamy czystszy kod
- adnotacja @NamedQuery
- ustawienie tego parametru ma wplyw na wydajnosc aplikacji
- mechanizm z Hibernate
- okresla jak hibernate ma dociagnac encje podprzedne
- najczesciej pojawia sie w relacji one-to-many
- polega na tym ze hibernate pobiera dane z bazy w n+1 zapytaniach
- n+1 zapytan - 1 zapytanie na glowna encje i n zapytan na encje podrzedne
- rozwiazanie: fetchmode, fetch, batchsize
- persistenceBag - domyslnie ustawione dla list
- set nie przechowuje duplikatow - list przechowuje duplikaty
- persistanceBag - nie zachowuje kolejnosci mimo ze jest implementacja listy
- set zajmuje wiecej pamieci od listy
- hibernetowa implementacja seta jest persistenceSet
- stosujac set w hibernacie trzeba pamietac o equals i hashcode
- order by w hqlce
- @OrderBy("nazwa_kolumny")
- najlepiej sortowac dane na poziomie bazy danych (wydajnosc) i nie zawracac tym sobie glowy w javie
- mapoowanie wyjatkow:
- natywne zapytania sql - wlasciwe sql dla danej bazy danych
- mechanizm ktory pozwala na wykonanie zwyklej slqki w hibernate
- obiekt Criteria Query na ktorym bedziemy okreslali rozne filtry
- Od Hibernate 5.x Criteria API jest zdeprecjonowane
- Tworcy Hibernate zdecydowali na tworzenie wlasnego Criteria API
- Zapytania zorientowane obiektowo
- cache of database connections maintained so that the connections can be reused when required
- HikariCP - najlepszy connection pool
- chodzi o to zeby nie otwierac co chwila nowego polaczenia do bazy danych tylko jest pewna pula
- tworzymy polaczenie i wrzucamy do worka i potem wyciagamy je z worka
- polaczen do bazy danych moze byc wiecej niz jedno - zaleznie od ilosci watkow
- troche podobnie jak Stringpool
- oszczednosc czasu i zasobow
- first level cache & second level cache
- cache - hardware or software component that stores data so that future requests for that data can be served faster
- cache jest po to zeby nie ladowac danych z bazy danych za kazdym razem
- first level cache jest wlaczony domyslne w hibernate -nie trzeba nic robic
- nie da sie go wylaczyc - jest to cache na poziomie sesji
- second level cache - cache na poziomie aplikacji
- kazdy obiekt session na swoj first level cache
- 1LC jest na sztywno zwiazany z session
- jest domyslnie wlaczony i nie mozna go wylaczyc
- obejmuje jedna sesje po zamknieciu sesji obiekty znikaja z pamieci
- Hibernate nie pozwala na zapisanie obiektu wiecej niz jeden raz
- jezeli w tej samej sesji pytamy 2 razy o ten sam obiekt to Hibernate zaladuje encje z first level cache
- caly 1LC mozna usunac przy uzyciu metody clear() na obiekcie session
- evic() - usuwa obiekt z 1LC
- clear() - usuwa caly 1LC
- cache na poziomie aplikacji
- cache jest wspoldzielony przez wszystkie sesje
- mozna go wylaczyc
- cache jest zalezny od dostawcy
- interfejs RegionFactory - java specyfikuje interfejsy ale trzeba go zaimplementowac
- jednym z dostawcow jest ehcache
- cache mozna konfigurowac w pliku xml
- adnotacje @Cache i @Cachable - Enable Selective - domyslnie zalecana
- Disable selective - @Cache(usage = CacheConcurrencyStrategy.NONE)
- database lock/database concurrency control
- locki w bazie danych - mechanizm blokowania wierszy w bazie danych
- locki w hibernate - mechanizm blokowania obiektow w hibernate
- locki w hibernate sa zalezne od dostawcy
- tematyka zwiazana z concurrency
- concurrency - wspolbieznosc - wielowatkowosc
- optimistic locking - optymistyczne blokowanie
- pessimistic locking - pesymistyczne blokowanie
- lock bazodanowy - mechanizm pozwalajacy na blokowanie danych w bazie danych
- kazdy uzytkownik strony internetowej ma swoja sesje bazodanowa
- jezeli wielu uzytkownikow dokonuje zmiany na danych to tylko jeden uzytkownik bedzie w stanie je zmienic
- hibernate obsluguje dwa rodzaje lockingu - optimistic oraz pessimistic
- zaklada ze konflikty sa mozliwe ale beda wystepowac rzadko
- wersjonowanie - dodanie kolumny wersji do tabeli
- wersjonowanie jest domyslnie wylaczone
- wersjonowanie jest wlaczone przez adnotacje @Version
- tutaj jest numerek o weryfikacji czy ktos juz przed nami nie zmienil danych
- zaklada ze konflikty sa mozliwe i beda wystepowac czesto
- zablokowanie zasobu na wylacznosc
- blokowanie dostepu do danych drugiemu uzytkownikowi az pierwszy skonczy swoje dzialanie
- ten drugi uzytkownik musi poczekac az drugi skonczy
- pesimistic locking jest jak toitoi - jak jedna osoba wejdzie to inne musza poczekac az sie toitoi zwolni
- uzytkownicy nie lubia czekac w aplikacjach internetowych
- najwieksza wada pessimistic locking jest to ze uzytkownicy musza czekac
- optimistic locking jest lepszy w aplikacjach internetowych
- zjawisko dead locka - sytuacja w ktorej dwa watki czekaja na siebie nawzajem
- pessimistic locking moze doprowadzic do dead locka - tzw. waskie gardlo
- moze dojsc do niezwolnienia zasobu i wtedy aplikacja sie zacina
- czesciej uzywa sie optimistic locking
- w praktyce ustawia sie timeout zeby osoby czekajace na zasoby nie czekaly wiecznosc