Question

Are there specified cases in JPA2 when a merge would not assign the @Id variable ? And yet return a new instance of the entity without firing an exception ?

Say I’m having this hierarchy:

@MappedSuperclass
abstract class Bar {

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

  ...
}

@Entity
@Table(name = "BAR_1S")
@Access(AccessType.PROPERTY)
class Bar1 extends Bar {
  ...
}

@Entity
@Table(name = "BAR_2S")
@Access(AccessType.PROPERTY)
class Bar2 extends Bar {
  ...
}

For a yet to be found reason the instances of Bar1 get an id after the merge() while instances of Bar2 don’t. At least that’s what it looks like. I’ve been trying various approaches at no prevail.

It looks like Hibernate (4.1.4.Final) doesn’t want to assign an id to instances of that particular class. 🙂

The questions I have:

• Did somebody ever had something like this ?

• Can somebody tell me where in Hibernate the id’s are set ? So I can debug that part of the code and find out why it skips the assignment. IntelliJ doesn’t seem to break on the modification of fields in entities.

EDIT – ENVIRONMENT CONFIGURATION

• OS: LMDE amd64
• Database: MySQL (5.1.61-2) ConnectJ (5.1.17)
• JVM: 1.7.0_04
• Hibernate: 4.1.4.Final
• Spring: 3.1.1

EDIT – CODE

All the entity classes are (in)direct subclasses of Bar. There is only one place where @Id is defined. And there a few identical cases of Bar2 that do get an id. But specifically Bar2 doesn’t.

final Bar1 bar = new Bar1();
JpaTemplate.merge(bar); <– gets an id

final Bar2 bar = new Bar2();
JpaTemplate.merge(bar); <– has no id

The application is using JpaTemplate of Spring to merge entities. Which runs okay for everything exception that particular class.

So, if I could find the Hibernate class assigning the id I would probably find out what silly detail I overlooked. 🙂

Answer 1

Found it ! The merge happens in an overloaded method annotated by @Transactional. I was assuming the overloading method would “inherit” the annotation. Which isn’t the case apparently.

By annotating the overloading method with @Transactional it seems to work.

Knew it would be a silly thing …