One-to-one i lazy loading

Hibernate jest frameworkiem, który nie przestaje zaskakiwać. Kryje się w nim mnóstwo tajemnic, pułapek i zagadek. Jedną taką pułapkę postaram się opisać w tym wpisie, a dotyczy ona nieoczywistego na pierwszy rzut oka zachowania adnotacji @OneToOne z parametrem fetchType=LAZY.

One-to-one

Adnotacja @OneToOne służy w JPA do oznaczania pól encji, które odnoszą się do obiektów będących z nią w relacji jeden-do-jeden. W znormalizowanym schemacie relacyjnej bazy danych oznacza to sytuację, w której mamy do czynienia z dwoma tabelami A oraz B, a jedna z nich posiada kolumnę, której wartości wskazują na klucz identyfikujący krotkę w drugiej z nich. Np:

Lazy fetch

Adnotacja @OneToOne zawiera również atrybut fetch, który może przyjąć wartości EAGER lub LAZY (domyślnie EAGER). O ile ustawienie wartości EAGER oznacza, iż Hibernate musi pobrać dodatkowy wiersz natychmiast (za pomocą klauzuli JOIN bądź dodatkowego zapytania) to zastosowanie LAZY może ale nie musi spowodować, iż dane zostaną dociągnięte tylko jeżeli faktycznie będą potrzebne w późniejszym czasie. Warto jednak zadać sobie pytanie, od czego to zależy?

Właściciel relacji

Należy zwrócić uwagę, iż adnotację @OneToOne można umieścić w obu powiązanych encjach. W przedstawionym wyżej przykładzie, zarówno klasa A reprezentująca tabelę A jak i klasa B reprezentująca tabelę B może posiadać pole oznaczone przez @OneToOne wskazujące na obiekt drugiej z nich. Jednak jeżeli przyjrzymy się schematowi bazy danych, zauważymy, iż tylko jedna tabela z nich posiada fizyczne wskazanie na wiersz w drugiej. To ona jest właścicielem relacji. Encja, która nie jest właścicielem relacji musi określić pole właściciela dzięki atrybutu mappedBy adnotacji @OneToOne.

Hibernate Lazy Proxy

Kolejnym elementem, który trzeba sobie uświadomić jest sposób w jaki Hibernate reprezentuje późno zaciągane obiekty w pamięci. Otóż w przypadku późnego dociągania zamiast obiektów danej klasy tworzone są obiekty proxy (anonimowych klas wygenerowanych przez Hibernate), które są odpowiedzialne za wykonanie dodatkowych zapytań w razie potrzeby. Problem pojawia się gdy podrzędny obiekt może nie istnieć w bazie danych. Co wtedy powinien zrobić ORM? Wstawić wartość null czy obiekt proxy? Hibernate jest w takiej sytuacji zmuszony zastosować strategię EAGER.

Do sedna

Do wyjaśnienia w jaki sposób odbywa się zarządzanie relacją one-to-one posłużę się prostym przykładem. Utworzyłem dwie proste encje: A oraz B, która jest właścicielem relacji. Dodatkowo napisałem dwa testy wyciągające obiekty tych klas dzięki repozytoriów Spring Data.

@Data
@Entity
@Table(name = "A")
public class A {

@Id
private Long id;

@Column
private String someProperty;

@OneToOne(mappedBy = "a", fetch = FetchType.LAZY)
private B b;
}
@Data
@Entity
@Table(name = "B")
public class B {

@Id
private Long id;

@Column
private String someProperty;

@OneToOne(fetch = FetchType.LAZY)
private A a;
}
@DataJpaTest
class RepositoryIT {

@Autowired
private ARepository aRepository;

@Autowired
private BRepository bRepository;

@Test
void testA() {
List<A> all = aRepository.findAll();
all.stream().findFirst().ifPresent(first -> {
System.out.println(first.getClass());
System.out.println(first.getB().getClass());
});
}

@Test
void testB() {
List<B> all = bRepository.findAll();
all.stream().findFirst().ifPresent(first -> {
System.out.println(first.getClass());
System.out.println(first.getA().getClass());
System.out.println(first.getA().getSomeProperty());
});
}
}
Output z testów prezentuje się następująco: testA: Hibernate: select a0_.id as id1_0_, a0_.some_property as some_pro2_0_ from a a0_
Hibernate: select b0_.id as id1_1_0_, b0_.a_id as a_id3_1_0_, b0_.some_property as some_pro2_1_0_ from b b0_ where b0_.a_id=?
class dev.maczkowski.onetooneexample.entity.A
class dev.maczkowski.onetooneexample.entity.B
example_value
testB: Hibernate: select b0_.id as id1_1_, b0_.a_id as a_id3_1_, b0_.some_property as some_pro2_1_ from b b0_
class dev.maczkowski.onetooneexample.entity.B
class dev.maczkowski.onetooneexample.entity.A$HibernateProxy$3Yd2tM5i
Hibernate: select a0_.id as id1_0_0_, a0_.some_property as some_pro2_0_0_ from a a0_ where a0_.id=?
example_value
Łatwo zauważyć, iż przy posługiwaniu się ARepository zostały wykonane dwa zapytania od razu. Ponadto pole b jest klasy dev.maczkowski.onetooneexample.entity.B. Stało się tak pomimo ustawienia atrybutu fetch = FetchType.LAZY. W drugim przypadku najpierw zostało wykonane jedno zapytanie, a pole a jest typu dev.maczkowski.onetooneexample.entity.A$HibernateProxy$3Yd2tM5i. Dopiero później zostało wykonane zapytanie inicjalizujące zawartość tego obiektu.

To tyle :)

Miał to być krótki wpis ale ostatecznie zdecydowałem się wszystko wyjaśnić od początku do końca. Jako ciekawostkę dopowiem, iż w przypadku relacji many-to-one sprawa wygląda nieco prościej ale domyślna wartość atrybutu fetchType jest inna i warto zwrócić na to uwagę.