Spring Boot + Hibernate + REST Api, wyciąganie rekordów z bazy

Cześć. Tworzę aplikację REST Api w której za pomocą odpowiednich końcówek chcę wyciągać z bazy odpowiednie dane.

Posiadam metodę która wyświeta z tabeli wszystkie rekordy w postaci listy

	@Override
	public List<City> findAll() {
		// get the current hibernate session
		Session currentSession = entityManager.unwrap(Session.class);
		
		// create a query
		Query<City> theQuery = currentSession.createQuery("from City", City.class);
		
		// execute query and get result list
		List<City> cities = theQuery.getResultList();
		
		// return the results
		return cities;
	}

I wszystko gra, po wejściu w odpowiedni link wyświetla się lista miast

Jednak kiedy próbuje troszke skomplikować to zapytanie

	@Override
	public List<City> findAllCitiesRidesGoesFrom() {
		Session currentSession = entityManager.unwrap(Session.class);
		Query<City> theQuery = currentSession.createQuery("SELECT DISTINCT city.id_city, city.city_name FROM city, ride WHERE ride.id_city_from = city.id_city", City.class);
		List<City> cities = theQuery.getResultList();
		return cities;
	}

dostaje błąd "org.hibernate.hql.internal.ast.QuerySyntaxException: city is not mapped" i wskazuje, że coś jest nie tak z zapytaniem

To samo zapytanie złożone w MySQL Workbenchu daje taki wynik

Wiecie może o co tu chodzi ? Co jest nie tak w tym zapytaniu ?

Jak używasz spring boota, to nie używaj gołego entity managera tylko spring data

a jak masz problem z kwerendą Hibernate, dlaczego zapodajesz temat z REST-em i Springiem?
Musisz nauczyć się dzielić /rozcinać /lokalizować problemy.

pominę użyteczność Hibernate, jak myślisz (i w sumie słusznie w pewnym kontekście) SQLem.
Nie każdy tutorial ma tę samą jakość, nie każda "technologia" Cię przenosi do lepszego stylu programowania, niektóre sa tylko przykrą pańszczyzną.
To że da się napisać w hibernate 'nieobiektową' kwerendę, 'prawie' tożsamą z SQL, to nie znaczy, że należy to robić. Masz wady obu technik, i żadnych zalet.

Wpisz w Google „HQL” i zapraszam do dokumentacji.

To co Ty chcesz to chyba Spring JdbcTemplate. Polecam

Ewneutalnie createNativeQuery zamiast createQuery

1. Wywal Hibernate
2. Wrzuć tam jakiś JDBC Template albo JOOQ
3. Napisz po ludzku query które cię interesuje
4. Zrób proste DTO z danymi które cię interesują
5. Profit!

Jedyne w czym pomaga Hibernate to:

1. Wyciąganie całej bazy danych do pamięci próbując wybrać cokolwiek z bazy (bo wszystko ze sobą połączone i wszystko EAGER)
2. Wywalanie produkcji za pomocą LazyInitializationException (bo akurat coś było LAZY)
3. Robienie nieoczekiwanych updatów, bo dotknąłeś obiektu attached a sesja była otwarta i zmiana obiektu od razu leci jako update do bazy

A jak już jesteśmy przy frameworkach bazodanowych.
Jaka najlepsza alternatywa ORM dla hibernate?
Co najlepsze wgl?
Co powiecie o MyBatis?

Korges napisał(a):

A jak już jesteśmy przy frameworkach bazodanowych.
Jaka najlepsza alternatywa ORM dla hibernate?
Co najlepsze wgl?

Eclipselink.
(na serio ale w tym kontekście żartem)

Tak naprawdę, to widać po pytaniu, że nie wiesz o co pytasz..
a) implementacji JPA innych 2) niż Hibernate jest widocznych na rynku ze 2-3 na bazach czysto relacyjnych (w tym Eclipselink 1) ), sa jakieś bazy obiektowe ze zintegrowanym poziomem JPA (nie używałem)
b) ciężki ORM w pełnym sensie tego słowa vs lekkie mapery (JDBI, iBatis, JOOQ, QueryDSL i jeszcze z pięć istotnych na rynku innych).
Hebernate & JPA miały większy sens w dawniejszych architekturach, gdzie śledzenie stanu obiektu np miało sens (w desktopach), ble ble ble. Nawet to, co dziś oceniamy jako wady, miał większy czy mniejszy sens.
W szczególności powstała w innych warunkach filozofia Hibernate/JPA mocno nie przystaje do dzisiejszych aplikacji webowych

Generalnie mapowanie obiektowo relacyjne ze względów zasadniczych nie jest ani proste, ani nigdy nie będzie w pełni satysfakcjonujące (to są mocno odległe paradygmaty), jest kompromisem.

1. który mapuje nie tylko do relacyjnych, ale do Mongo (częściow, bo tylko tyle jest możliwe) i innych cudaków
2. nie wiem, czy tą różnicę czujesz.

Korges napisał(a):

A jak już jesteśmy przy frameworkach bazodanowych.
Jaka najlepsza alternatywa ORM dla hibernate?
Co najlepsze wgl?

JOOQ (jak mozna wygenerować klasy reprezentujace tabele z bazy), JDBI (jeśli z jakiegoś dziwnego powodu mie można wygenerować klas), w ostateczności JDBCTemplate

Syntax w kodzie SQL a syntax w Workbenchu są różne. Powinieneś spróbować coś takiego

List<Object[]> cities = session.createNativeQuery("SELECT DISTINCT city.id_city, city.city_name FROM city, ride WHERE ride.id_city_from = city.id_city").list();

Później odpowiednio "mapować" na docelowe obiekty. Jest sporo zabawy ale i jest też fun.

KamilAdam napisał(a):

Korges napisał(a):

A jak już jesteśmy przy frameworkach bazodanowych.
Jaka najlepsza alternatywa ORM dla hibernate?
Co najlepsze wgl?

JOOQ (jak mozna wygenerować klasy reprezentujace tabele z bazy), JDBI (jeśli z jakiegoś dziwnego powodu mie można wygenerować klas), w ostateczności JDBCTemplate

Oglądam Twoją wypowiedź od wczoraj, i chyba już wiem, co powiedzieć.

Dostępność do bazy chyba nie jest najważniejszym kryterium, choć rzeczywiście (z rzadka) można nie mieć do niej koniecznego trybu dostępu.

Chyba najważniejsza jest decyzja, czy chcemy typesafe JOOQ (aka Criteria done well) i kwerendy nam podkładają automaty, a może chcemy wykorzystać umiejętności w SQLu?
Może kwerendy są mocno ręcznie optymalizowane, albo baza nie jest w pełni elegancka (np normalizacja do stopnia 2 1/2), albo mocno obciążona zaszłościami historycznymi?
Albo kwerendy już posiadamy z poprzedniej generacji projektu, i w nowym projekcie się migrujemy.

*(dla początkujących / działaniu nie na pełny wymiar etatu itd płatna licencja za np MS SQL, a to wiodąca baza, może być ważna) *

@AnyKtokolwiek: tak masz racje. Wczoraj za dużo wypiłem zeby pisać wystarczajaco jasno. Chodzilo mi o to ze jeśli mozna użyć JOOQ to najlepiej użyć JOOQ

AnyKtokolwiek napisał(a):

Dostępność do bazy chyba nie jest najważniejszym kryterium, choć rzeczywiście (z rzadka) można nie mieć do niej koniecznego trybu dostępu.

Chyba najważniejsza jest decyzja, czy chcemy typesafe JOOQ (aka Criteria done well) i kwerendy nam podkładają automaty, a może chcemy wykorzystać umiejętności w SQLu?

Nie do końca rozumiem twoją wypowiedź. JOOQ celuje właśnie w target ludzi chcących pisać natywny SQL. JOOQ to natywny SQL tylko sprawdzany składniowo.
wykorzystać umiejętności w SQLu to wręcz slogan reklamowy autora JOOQ (Lukas Eder).
Nie ma tam żadnej magii, optymalizacji - SQL jest taki jak go sobie napiszesz. Są dostępne rozszerzenia (dialekty) specyficzne dla konkretnej bazy (Oracle, MS SQL itd).