Zawsze używaj prymitywnych opakowań obiektów dla JPA @Id zamiast typu pierwotnego?

Znalazłem problem z użyciem typu prymitywnego jako obiektu @Id dla JPA w połączeniu z JPA Spring Data. Mam relację rodzic / dziecko z Cascade.ALL po stronie rodzica, a dziecko ma PK, który jednocześnie jest FK rodzica.

class Parent {
    @Id
    private long id;

    @OneToOne(mappedBy = "parent", cascade = ALL)
    private Child child;
}

class Child {
    @Id
    @OneToOne
    private Parent parent;
}

Więc kiedy biegam:

...
Parent parent = new Parent();
Child child  = new Child(parent);
parent.setChild(child);  
em.persist(parent)
...

wszystko dziala. Ale użyłem Spring Data JPA do utrwalenia encji, więc uruchamiam zamiast tego:

parentRepository.save(parent); // instead of em.persist(parent);

a ten nie powiódł się z następującym wyjątkiem:

Caused by: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: Parent

Problem polegał na tym, że JPA Spring Datazapisać() metoda sprawdza, czy jednostka jest nowa i czy jest nowaem.persist () jest używany inaczejem.merge () jest używany.

Ciekawą częścią tego, jak Spring sprawdza, czy jednostka jest nowa, czy nie:

getId(entity) == null;

I oczywiście było to fałszywe, ponieważ użyłem długo jako typu @Id, a wartość domyślna dla long to 0. Kiedy zmieniłem długo na Long, wszystko działa także z JPA Spring Data.

Czy zatem zalecaną praktyką jest zawsze używanie opakowań obiektowych dla typów pierwotnych (takich jak Long zamiast long) zamiast typów prymitywnych. Wszelkie zasoby innych firm opisujące to jako zalecaną praktykę byłyby bardzo miłe.

questionAnswers(2)

yourAnswerToTheQuestion