Jako že je to kanón na vrabce pro takový jednoduchý update?
To samozřejmě je, ale hibernate a) zajistí transparentnost persistentní vrstvy, nemusím se starat, kde jsou data, jaká tabulka a názvy sloupečků, b) vyřeší SQL dialekty (ač tady asi celkem jednoduché), c) v případě trochu složitějších embedded struktur už zajistí mapování (tady není ten případ).
Spis jako proc pouzivat ORM framework, kdyz ho nepouzivam jako ORM. Me osobne neprijde koser ani ta druha konstrukce ve smyslu, ze vytvorim novou entitni tridu, pridelim ji id a potom nad ni dam delete. Neprijde mi jako extra problem si u kazdeho radku nest i referenci na tu entitni tridu a pracovat s ni rovnou. Ale to je uz muj subjektivni nazor a necham se rad poucit jak se to dela v jinejch dev teamech.
Pokud vidím, dobře, jsou uvedeny obě varianty - přes HQL i saveOrUpdate.
Co se týče HQL - loadovat celý objekt z DB, updatnout jeden sloupec a vrátit zpátky má přecejen docela overhead. Pokud bude objekt velký, nedej bože v budoucnu přibudou nějaké EAGER vazby, tak HQL na jeden rychlý update začne dávat smysl.,
Pokud vidím, dobře, jsou uvedeny obě varianty - přes HQL i saveOrUpdate.
Co se týče HQL - loadovat celý objekt z DB, updatnout jeden sloupec a vrátit zpátky má přecejen docela overhead. Pokud bude objekt velký, nedej bože v budoucnu přibudou nějaké EAGER vazby, tak HQL na jeden rychlý update začne dávat smysl.
A jestli hibernate ano nebo ne - za mě ano, skoro vždycky. Matlat se někde s SQL a řešit pak tuny neportabilního kódu opravdu dneska nemá smysl. I když použiju jen subset, třeba bez mapování...