HSQLDB nie jest traktowana jako baza „na produkcję”. Choć w pewnych specyficznych przypadkach świetnie sprawdza się jako podstawowy silnik RDBMS to zazwyczaj stosujemy ją tylko jako narzędzie do testów integracyjnych dla DAO.

Ja trafiłem jednak na przypadek gdzie HSQLDB została wybrana jako główna baza danych dla produktu. Trafiłem też na ciekawy „feature” tego silnika. Otóż jeżeli po raz pierwszy łączymy się z bazą danych, nieistotne jest czy bezpośrednio za pomocą JDBC czy z nakładką w postaci JPA, to nawet jeżeli baza nie istnieje to wszystko przebiega pomyślnie. Oczywiście chodzi nam w tym przypadku o połączenie z bazą działającą w trybie file, a nie memory. Jeżeli zakończymy pracę z bazą i będziemy chcieli ponownie uruchomić aplikację to okaże się, że dane „były znikły nie ma ich”. Nie dobrze. Szczególnie, że klient chciał by nic nie trzeba było instalować. Szybki reaserch w dokumentacji i…

Zarówno w wersji 1.X jak i 2.X jeżeli wybierzemy pracę w trybie file tworzony jest plik konfiguracyjny .properties. W nim można skonfigurować różne elementy silnika HSQLDB m.n. to jak tworzone są tabele. I tu jest cały myk. HSQLDB domyślnie tworzy wszystkie tabele jako memory, czyli po zakończeniu pracy „tabele papa”.

Flaga hsqldb.default\_table\_type=cached rozwiązuje problem.