log4j.logger.org.hibernate.SQL=DEBUG
log4j.logger.org.hibernate.type=TRACE


Then you will see everything in your log. For example:


7820 DEBUG [org.hibernate.SQL] {main} - insert into Client (name, personalNumber, id) values (?, ?, ?)
7821 TRACE [org.hibernate.type.StringType] {main} - binding 'John Doe' to parameter: 1
7821 TRACE [org.hibernate.type.StringType] {main} - binding '123X' to parameter: 2
7821 TRACE [org.hibernate.type.LongType] {main} - binding '10' to parameter: 3


O co jde? Když mapuji entity, můžu si vybrat, jak bude Hibernate k objektům přistupovat. Mohu například napsat takovouto třídu.

@Entity
@Configurable
public class Client  {

	@Id @GeneratedValue(strategy=GenerationType.SEQUENCE)
	private Long id;

	@Column(unique=true,nullable=false)
	private String personalNumber;

	...
}

V takovémto případě bude při načítání z databáze Hibernate data zapisovat přímo do polí. To znamená, že například pro ID nemusíme mít vůbec set metodu, Hibernate nebo jiný JPA poskytovatel to tam magicky zapíše.

Nebo mohu zvolit druhou variantu.

@Entity
public class ClientGroup {

	private Long id;

	private List clients = new ArrayList();

	private String name;

	@Id @GeneratedValue(strategy=GenerationType.SEQUENCE)
	public Long getId() {
		return id;
	}

	private void setId(Long id) {
		this.id = id;
	}

	@OneToMany(cascade=CascadeType.ALL)
	public List getClients() {
		return clients;
	}

	private void setClients(List clients) {
		this.clients = clients;
	}
	public void addClient(Client client)
	{
		clients.add(client);
	}
	...
}

V tomto případě jsem dal anotace nad get metody a Hibernatu jsem tím dal najevo, že má pro přístup používat vlastnosti (property). Tzn. při plnění instancí z databáze bude volat set metody, při ukládání do databáze bude používat hodnoty z get metod.

Protože tu tvrdošíjně používám českou terminologii, shrnu to do slovníku.
Field access – přístup pomocí polí – anotace nad poli
Property access – přístup pomocí vlastností – anotace nad get metodami

Dobrá zpráva je, že v jednom programu mohu používat oba přístupy. Jednu třídu mohu mapovat tak, druhou onak. Sice bych to moc nedoporučoval, ale teoreticky to jde. U jednotlivých tříd ale oba přístupy míchat nemůžeme. Nemohu si říci, že ID chci mapovat jako field a seznam klientů jako property. Specifikaci už si nepamatuji, ale v praxi to funguje tak, že se typ přístupu určuje podle toho, nad co dám anotaci @Id.

Takže tu máme dva různé přístupy a nabízí se otázka, který je vhodnější. Oba mají svá pro a proti. Já osobně preferuji přístup přes pole. Prostě se smířím s tím, že mi Hibernate magicky mění vnitřnosti objektu. Podle některých to porušuje zapouzdření. Částečně mají tito lidé pravdu, ale tento přístup je podle mě menším ze dvou zel. Radši se smířím s tím, že mi zapouzdření bude narušovat Hibernate, než abych se smířil s tím, že mi ho bude narušovat programátor.

Vezměme si příklad ID. To je obvykle nastavováno Hibernatem. Rozhodně nechci, aby mi ho nastavoval nebo měnil programátor. V případě přístupu přes pole jednoduše nevytvořím set metodu a mám hotovo. V případě přístupu přes vlastnost musím vytvořit set metodu. Může být klidně i private, ale musí tam být. Takže stejně musím nechat Hibernate, aby mi prolomil zapouzdření. Stejně ho musím nechat volat private metodu. Nebo ji mohu nechat public, ale pak se musím modlit, aby mi někdo ID nezměnil. Mě osobně připadá čistší tam ten setter vůbec nedávat.

Podobný problém je i u kolekcí. Obvykle nechci nechat programátora, aby mi kolekci nastavoval přímo (viz. ClientGroup příklad). Ale u přístupu pomocí vlastností stejně musím mít set metodu, i když opět může být private.

Property přístup je podle mě také o trochu náchylnější na chybu. Představme si, že do objektu přidáme metodu getFullName, která jen zřetězí křestní jméno a příjmení. Když máme anotace nad poli, není tu žádný problém, pokud máme anotace nad metodami, tak si bude JPA myslet, že chceme mít v databázi sloupeček FULL_NAME a ošklivě nám vynadá. Budeme to muset vyřešit dobře mířenou anotací @Transient.

Specifickou kapitolou jsou netriviální get a set metody. V set metodách můžu mít validace vstupních hodnot, v get metodách vracet defenzivní kopie. U přístupu přes pole to není problém. Ale pokud používám přístup pomocí vlastností tak se mohou dít ošklivé věci. Validační kód se bude volat při každém načtení z databáze, což může mít na výkonnost dopad jen malý. Horší je to s defenzivními kopiemi. Ty mohou ovlivnit mechanismus detekce změn. Pokud budu například vracet defenzivní kopii kolekce, Hibernate bude přesvědčen, že se mu změnil obsah kolekce a pokaždé danou kolekci z databáze smaže a vloží ji tam znovu. A to i v situaci, že jsme danou instanci vůbec nezměnili! To může mít na výkonnost dopad dost ošklivý.

Teď mi zrovna došlo, v čem je problém. V podstatě obvykle potřebujeme, aby entita měla dvě rozhraní. Jedno pro programátory, druhé pro perzistenci. To je přesně to, co mi zajistí mapování přes pole. Říkám tím, že ORM je taková chytřejší serializace po které chci aby mi uložila stav objektu. U klasické Java serializace si taky nikdo nestěžuje, že narušuje zapozdření tím, že nastavuje pole napřímo. Při přístupu přes vlastnosti na druhou stranu tvrdím, že ORM a programátor jsou si rovni a že by měli používat stejné rozhraní. Někdy to tak být může, ale obvykle tomu tak není.

Předchozí věta by tvořila pěkný závěr článku, naneštěstí ale ještě končit nemůžu. Je jeden konkrétní případ, kdy jsou anotace nad metodami lepší volba. Je to v případě, že načítáme ID u lazy proxy, které ještě není načtené z databáze. Řekněme, že dělám například toto:

clientGroup.getClient(0).getId()

Může se stát, že Hibernate zná jenom ID klientů, kteří patří do dané skupiny, ale ještě nemá načtená jejich data. V tom případe se používá proxy, která zajistí načtení dat, až když jsou potřeba. Když používám přístup pomocí polí, Hibernate musí všechny informace o klientovi načíst, i když mě zajímá jen ID. Neví totiž, že metoda getId() jenom vrací klíč. Neví jestli náhodou v této metodě nečtu třeba jméno. Nemá šanci to poznat. Teoreticky by se mohl podívat do kódu, ale to by už bylo příliš mnoho magie. Na druhou stranu pokud mám nad metodou getId() anotaci @Id, Hibernate ví, že to je ID a může mi ho rovnou vrátit, aniž by musel přistupovat do databáze.

Ale toto je jediný případ, v kterém je přístup přes vlastnosti lepší. Záleží případ od případu, jestli zrovna tuto vlastnost použiji. Dovedu si představit aplikaci, kde budu například ID používat i v UI pro odkazy v tabulce. Dovoluji si ale tvrdit, že i tak by bylo lepší použít nějakou lepší fetch strategii než se prát s anotacemi nad metodami. Jinak to totiž zavání předčasnou optimalizací.

Další čtení:
http://forum.hibernate.org/viewtopic.php?p=2349555&sid=dd846f97d3eb352ed0b8fbe57739801c

http://chstath.blogspot.com/2007/05/field-access-vs-property-access-in-jpa.html

http://shashivelur.com/blog/2009/01/hibernate-direct-field-acess-and-encapsulation/

It is simple to define interceptor in persistence.xml using hibernate.ejb.interceptor property. But it is only possible to specify class name, you can not inject Spring bean. If you read documentation to Spring LocalContainerEntityManagerFactoryBean there is no possibility to specify the interceptor bean there neither. But there is a way how to achieve it. First of all, you have to redefine Hibernate PersistenceProvider.

public class ConfigurableHibernatePersistence extends HibernatePersistence {
	private Interceptor interceptor;
	public Interceptor getInterceptor() {
		return interceptor;
	}

	public void setInterceptor(Interceptor interceptor) {
		this.interceptor = interceptor;
	}

	@SuppressWarnings("unchecked")
	@Override
	public EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map) {
		Ejb3Configuration cfg = new Ejb3Configuration();
		Ejb3Configuration configured = cfg.configure( info, map );
		postprocessConfiguration(info, map, configured);
		return configured != null ? configured.buildEntityManagerFactory() : null;
	}

	@SuppressWarnings("unchecked")
	protected void postprocessConfiguration(PersistenceUnitInfo info, Map map, Ejb3Configuration configured) {
		if (this.interceptor != null)
		{
			if (configured.getInterceptor()==null || EmptyInterceptor.class.equals(configured.getInterceptor().getClass()))
			{
				configured.setInterceptor(this.interceptor);
			}
			else
			{
				throw new IllegalStateException("Hibernate interceptor already set in persistence.xml ("+configured.getInterceptor()+")");
			}
		}
	}
}

(source)

Here we override method createContainerEntityManagerFactory in order to add postprocessConfiguration method call. In this method, it is possible to change Hibernate configuration as needed. Now the only thing to be done is configuring Spring to use our new PersistenceProvider. It is quite simple.

	<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
		<property name="persistenceUnitName" value="testPU" />
		<property name="dataSource" ref="dataSource" />
		<property name="persistenceProvider">
			<bean class="net.krecan.javacrumbs.jpa.interceptor.ConfigurableHibernatePersistence">
				<property name="interceptor">
					<bean class="net.krecan.javacrumbs.jpa.interceptor.SpringInjectingInterceptor"/>
				</property>
			</bean>
		</property>
	</bean>

And that all folks, we have Spring configured interceptor even when using JPA abstraction. It would be better if similar classes were in Spring or Hibernate, but it's just few lines of code so feel free to copy them if you need to. If you know easier way how to do it, please mention it in the comments below.

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
	<property name="persistenceUnitName" value="testPU" />
	<property name="dataSource" ref="dataSource" />
	<property name="jpaProperties">
		<props>
			<prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto}</prop>
		</props>
	</property>
</bean>

It works nice, without any problem. But imagine that one day you need to access Hibernate statistics. To achieve this, you have to have access to the Hibernate session factory. But we have no session factory here, we are using the entity manager which hides session factory underneath. How to access it? The solution is simple, you can use factory method.

<!-- Publishing session factory to be able view statistics -->
<bean id="sessionFactory" factory-bean="entityManagerFactory" factory-method="getSessionFactory" />

By this simple code we say to Spring: Hey, just call the method getSessionFactory on the entityManagerFactory bean and store the result as a bean with name sessionFactory. Since we are using Hibernate as the JPA provider, entityManagerFactory is instance of HibernateEntityManagerFactory and by a chance it has getSessionFactory method. Now we have access to the session factory and we can use it however we like.

Note: If you wonder why the hell I have started to write in something that looks almost like English when apparently I do even more mistakes than in Czech, the answer is simple. I just need to practice my English (apart from that I want to be world famous, not just known in Czech Republic)

When you are modifying data using Hibernate, you have to keep in mind that Hibernate uses so called write-behind. It means that Hibernate propagates changes to the database as late as possible. By default this propagation (flushing) happens at the following times

• when transaction is committed
• before query is executed
• when flush() method is called explicitly

Usually such behavior is a good thing. It enables Hibernate to optimize data modifications and allows grouping many changes to one big batch update. But sometimes you can encounter some interesting issues. Lets show it on some example. Lets have following entity class:

We see that a client has id which is used internally as an identifier. Moreover a client has a personal number which we are using as a business key. Then he has some other attributes as name. Notice that the personal number is obligatory and it has to be unique.

We can test flushing by the following code, using ClinetDao:

When it is executed on HSQLDB we get following output (we see my logging messages mixed with Hibernate SQL output).

We see that inserts are called at once. They are not postponed until flush. In this case, Hibernate has to call insert at once because it has to get the client id from the database. (remember all non-transient entities have to have id) So inserts can not wait until flush, they have to be executed directly. In order to make our example more clear, we can change id generation strategy to sequence.

To get the client id, insert is not needed any more. It can be postponed until flush and we get following output

As you can see creation of the first client and his deletion is realized just before the select statement. Changes have to be propagated to the DB so the select statement has access to changed data. You can notice, that there is no update, change of the name was already included into the insert statement. So far so good. Where is the problem? Lets comment out the query (You do not have to comment it out, in the real world it can be bypassed by the second-level cache).

We get following output

Wow. It looks like Hibernate is trying to insert both clients with the same personal number without deleting the first one. Lets try to remove uniqueness condition from the client and take a look at the output:

Yes, Hibernate changed order of the commands! Without the unique constraint it does not matter, final result is the same. But with the constraint enabled, we can not use our code any more. Is it a bug? No, it is a feature. If you dig deep into the Hibernate source code, you will find following comment

Execute all SQL and second-level cache updates, in a
special order so that foreign-key constraints cannot
be violated:

1. Inserts, in the order they were performed
2. Updates
3. Deletion of collection elements
4. Insertion of collection elements
5. Deletes, in the order they were performed

And that is exactly our case. When flushing, Hibernate executes all inserts before delete statements.

So if we need to run our example, we have to force Hibernate to flush the delete before the second insert. The best way is to call entityManager.flush() explicitly just after the delete.

To reiterate, Hibernate is using write-behind. All data manipulating statements are executed as late as possible. One exception are insert statements. Sometimes Hibernate needs to call insert in order to get the ID of the entity. The important point is, that order of the commands can be changed by Hibernate. Usually it does not matter, since transactions are atomic. But sometimes we can encounter interesting issues. Especially when using database constraints.

The source code can be downloaded from SVN repository.

Note: If you wonder why the hell I have started to write in something that looks almost like English when apparently I do even more mistakes than in Czech, the answer is simple. I just need to practice my English (apart from that I want to be world famous, not just known in Czech Republic)

JPA vznikalo v situaci, kdy bylo na trhu několik dodavatelů O/R mapovacích nástrojů. Mnozí z nich se i na jeho vývoji podíleli. Nemůže nás proto překvapovat, že JPA pokrývá jenom podmnožinu průniku funkčností, které existující nástroje umožňovaly. To co uměl například Hiberante oproti Toplinku se do standardu prostě dostat nemohlo. Platí to samozřejmě i naopak. V tomto článku, bych chtěl shrnout pár věcí, které mi v JPA chybí.

Vlastní typy (UserTypes , Custom types)

JPA umožňuje ukládat jenom následující typy:

Java primitive types; java.lang.String; other Java serializable types (including wrappers of the primitive types, java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp, user-defined serializable types, byte[], Byte[], char[], and Character[]); enums; entity types and/or collections of entity types; and embeddable classes

Na první pohled by se mohlo stát, že to stačí. Nicméně co dělat, když máme například položku typu java.net.URL a chceme ji uložit jako String? Pomocí JPA se vám ji podaří uložit jedině v serializované podobě. Zajímavou diskuzi k tomuto tématu najdete na TSS.

Criteria API

Criteria API je funkčnost Hibernate, které se hodí, když skládáme databázový dotaz za běhu. Například, pokud máme formulář pro uživatelsky definovaný filtr. Bez criteria API musíme skládat dotaz do řetězce jen proto, aby si ho mohl JPA provider vzápětí naparsovat a složit z něj SQL řetězec. To se mi zdá trochu postavené na hlavu.

Jednosměrné one-to-many vztahy bez join tabulky

Více na jednom z předchozích příspěvků. Například Toplink Essentials tyto vazby opravdu nepodporuje.

Zabíjení sirotečků (delete-orphan)

Umožňuje nám automaticky mazat prvky, které jsme odebrali z one-to-many asociace. Mám-li například třídu klient, která obsahuje kolekci adres, delete orphan mi zajistí automatické smazání adresy poté, co ji odeberu z kolekce. Jelikož JPA tuto funkcionalitu nepodporuji, je nutné adresy mazat ručně, což v některých situacích může být dost komplikované. Více se můžete dočíst v dokumentaci k Hibernate.

Nastavení pro ladění výkonu

Například BatchSize a další. Ladění výkonu je věc, na kterou obvykle v aplikacích typu HalloWord nenarazíte. Pokud ovšem budete psát reálnou aplikaci, bez těchto funkcionalit se neobejdete. A JPA vám kromě možnosti psaní si vlastního SQL mnoho pomoci nenabídne.

Další věci, které nejsou pokryty standardem, ale například Hibernate je umožňuje, můžeme najít na v dokumentaci k Hibernate Extensions.

A co nám z toho plyne? JPA udělalo velikou práci v tom, že sjednotilo metadata pro O/R mapování. Pokud vám nevadí psaní metadat v anotacích, určitě je dobré tento standard používat. Zajistíte si tím snazší přenositelnost na jiného JPA providera. Je ale nepravděpodobné, že se vám podaří napsat a provozovat aplikaci čistě v JPA, aniž by byla závislá na konkrétní implementaci. Pokud se tedy vzdáme iluze o snadné přenositelnosti, je podle mého názoru nejrozumnější používat JPA jenom na definici metadat. Pro DAO vrstvu bych už používal implementaci, na kterou už jsme tak jako tak vázáni. Tzn. v případě Hibernate by to byl Springovský HibernateTemplate, který mi umožní používat HQL a Criteria API.

A to je právě to krásné na JPA, nenutí mě brát všechno nebo nic. Dává mi svobodu vybrat si jak moc ho chci používat. Mohu si vybrat jestli ho chci „degradovat“ jen na formu zápisu metadat nebo jestli mi jeho omezení stojí za tu iluzi snadné přenositelnosti.

Na svoji obhajobu mohu uvést jen to, že jsem to v době psaní článku moc neřešil a narazil jsem na dokumentaci, která naznačovala, že to není nijak moc jednoduché. A hlavně, abych nevypadal jako úplný blbec, ponořil jsem se do specifikace EJB 3.0. Tam jsem na straně 185 našel následující text

Unidirectional one-to-many relationships may be implemented using one-to-many foreign key mappings, however, such support is not required in this release. Applications that want to use a foreign key mapping strategy for one-to-many relationships should make these relationships bidirectional to ensure portability.

Takže se mohu vymlouvat, že jsem tu relaci udělal obousměrnou, abych zařídil přenositelnost.

Ale dost už bylo výmluv, podívejme se na to jak ono mapování zařídit. Připomenu jen, že vytváříme třídu Client, která obsahuje kolekci adres a účtů (viz. obrázek)

Všimněte si prosím anotace @JoinColumn(name="client_id", nullable=false), která nám zajistí požadované mapovaní přes cizí klíč. Důležitý je druhý atribut - nullable. Ten Hibernatu říká, že cizí klíč client_id v tabulce address nesmí obsahovat null.

Oproti minulé verzi vidíme značné zjednodušení. Nemusíme se starat o plnění druhého směru relace. Dokonce ani neuděláme stejnou chybu jako já minule, když jsem zapomněl vyřešit předávání adresy mezi klienty (automatické odebrání adresy jednomu klientovi, při přidání druhému). Abych to ještě více zjednodušil, použil jsem přehlednější, i když méně výkonnou, formu inicializace množiny adres.

Takže pro shrnutí, jednosměrná one-to-many relace v Hibernate funguje, nicméně není přenositelná v rámci EJB 3.0. Ještě bych chtěl na závěr poděkovat Markovi L. za to, že mě upozornil na spoustu chyb v minulém článku a ukázal mi, že by to mapování měl Hibernate přeci jenom umět.

Zdrojové kódy můžete stáhnout zde.

Zdroje:

1. JSR 220: Enterprise JavaBeansTM,Version 3.0
2. Hibernate dokumentace
   
3. EJB 3.0 – still trying to catch up to JDO and Hibernate
4. Getting Started with Hibernate