Always use primitive object wrappers for JPA @Id instead of primitive type?

Question

I've found the issue with using primitive type as an object @Id for JPA in conjunction with Spring Data JPA. I have parent/child relationship with Cascade.ALL on the parent side, and child has PK which at the same time is also parent's FK.

class Parent {
    @Id
    private long id;

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

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

So, when I run:

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

everything works fine. But I used Spring Data JPA to persist the entity, so I run instead:

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

and this one was failed with the following exception:

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

The problem was that Spring Data JPA save() method checks whether the entity is new, and if it is new then em.persist() is used otherwise em.merge() is used.

The interesting part here how Spring checks whether the entity is new or not:

getId(entity) == null;

And, of course, this was false, because I used long as the type for @Id, and the default value for long is 0. When I changed long to Long everything works with Spring Data JPA also.

So is it the recommended practice always to use object wrappers for the primitive types (like Long instead of long) instead of primitive types. Any 3rd party resource describing this as the recommended practice would be very nice.

Answer 1

I would say yes it is recommended to use object types instead of primitives because of the case you are seeing. There is no way of distinguishing if the entity is new or pre existing with a primitive identifier. I have used hibernate for years and I always use objects for identifiers.

Answer 2

I would use an object type. In the xml mapping, you could put an "unsaved-value" attribute, but i don't think there is a direct translation to the annotations for this. As a result, it's safer to stick with object types.

And most programmers would expect a "null" value in an identifier to mean unsaved anyway.