views:

54

answers:

2

Imagine, an Event entity references a Status Entity:

@Entity
@Table(name = "event")
public class Event()
{
  @Id
  @Column(name = "id", nullable = false)
  private long id;
  ...

  @ManyToOne
  @JoinColumn(name = "status_code", nullable = false)
  private Status status;
}


@Entity
@Table(name = "status")
public class Status()
{
  @Id
  @Column(name = "code", nullable = false)
  private String code;

  @Column(name = "label", nullable = false, updatable = false)
  private String label;
}

Status is mapped to a small table 'status'. Status is a typical reference data / lookup Entity.

   code  label
   ----- --------------
   CRD   Created
   ITD   Initiated
   PSD   Paused
   CCD   Cancelled
   ABD   Aborted

I'm not sure if it is a good idea to model Status as an Entity. It feels more like an enumeration of constants...

By mapping Status as an Entity, I can use Status objects in Java code, and the Status values are equally present in the database. This is good for reporting.

On the other hand, if I want to set a particular Status to an Event, I can't simply assign the constant status I have in mind. I have to lookup the right entity first:

event.setStatus(entityManager.find(Status.class, "CRD"))

Can I avoid the above code fragment? I'm affraid for a performance penalty and it looks very heavy...

  • Do I have to tweak things with read-only attributes?
  • Can I prefetch these lookup entities and use them as constants?
  • Did I miss a crucial JPA feature?
  • ...?

All opinions / suggestions / recommendations are welcome!

Thank you! J.

+1  A: 

Can I avoid the above code fragment? I'm affraid for a performance penalty and it looks very heavy?

Well, you could use an enum instead. I don't really see why you don't actually.

But if you really want to use an entity, then it would be a perfect candidate for 2nd level caching and this would solve your performance concern.

Pascal Thivent
I could model Status as an enumeration. This would allow for clean and efficient setting of Status values in an Event. Both the 'code' and the 'label' could be modelled as attributes. That's cool too. However, do I understand correctly that the 'label' information is not available in the database then? This is a bit unfortunate for external reporting: tools outside my Java app that might want to access the database. Or do I overlook something? Can Enums be mapped to their own database table as well?
Jan
I'll have to have a closer look at the second-level cache. By accident, do you know of any tools that allow for easy monitoring of the second-level cache in Hibernate?
Jan
@Jan Right, you wouldn't have the label in the database with an enum. But I would actually use `Created`, `Initiated`, etc in the enum, not the code. Anyway, it's indeed maybe better for you to use an entity. And in that case, @Jörn advice is a good one. Still, this read-only entity would be a perfect candidate for L2 caching. Regarding monitoring, it depends on the L2 cache provider.
Pascal Thivent
Thx. I agree that I need this L2 cache thingy up and running.
Jan
+1  A: 

You could use entityManager.getReference(Status.class, "CRD"), which might not fetch the entity from the database if it is only used to set a foreign key.

Jörn Horstmann
Good! That's the kind of hints I was looking for.
Jan