CODEWITHSUNDEEP
hibernatejakarta-eeormjpa-2.0
b3bop
b3bop

Reputation: 3683

JPA entity model proposal

I am trying to design an entity model using JPA2.0 via hibernate.

I have a domain like this: There are a bunch of restaurants, so obviously there is a restaurant entity. Each restaurant has a number of different dishes that it serves and 0-to-many restaurants may serve the same thing. Each dish has a number of ingredients, and some dishes will share ingredients. Each ingredients has several nutrients, and again each nutrient might be possessed by 0-to-many of the ingredients.

Im struggling because Im not even sure exactly what my problem is, but I know that I am missing something. I believe the question lies in how exactly to enforce the domain model and what are the implications for primary keys and .equals/.hashcode methods.

Originally I was going to use a generated surrogate key. Each entity would have something like

@Id
@GeneratedValue
public Long id;

And the .equals would test equality for all the entities members except id. For example a restaurant would be equal no matter the value of Long id, but in the equality of its List member. (and of course Dish would keep calling .equals all teh way down the hirarchy to nutrients.)

So when I give a DAO bean a restaurant, I only want it persisted iff there are no eqivalent restaurants in the data store (via .equals). But I guess that would involve a rather laborious jpql call, which I don't find elegant or efficient (please let me know if I am wrong. I am often wrong... lol). Further along the way, if it encountered say an ingredient that was already in the data store (but part of a dish that was not and therefore newly persisted) it would associate new dish with the ingredient already there rather than creating an entirely new (and logically duplicate) ingredient.

The more I thought About it, the more painful it sounded to persist things higher up in this heirarchy.

I started to look into the idea of a composite Key (via @IdClass or @EmbeddedId) that would itself hold the child members. This seems like persisting things higher in the hierarchy would be as simple as finding by id and persisting if I dont find anything. But I'm very suspicious of this... It does not seem right. It would mean that I am creating entities where all members and entities themselves and part of the composite key.

Some things to note. There are a relatively finite amount of nutrients. The space for ingredients is {numOfNutrients}^{typesOfNutrients} which could be fairly large. by the time we get up to restaurants, it will be almost impossible for a client to construct a duplicate resaurant by acccident as the space will be truly large. There comes a point when I don't actually care if a duplicate is in the data store, because it is so unlikely to happen. In fact it would almost be interesting to see if this occurred. Also not that the restaurant example is contrived. My real domain is similar in form though.

Sorry for the rambling. I know there are a lot of ideas in post. But I feel they are all so related, I wanted to bring them up all at once.

Can someone please offer some wizardry?

I am aware of this post: A class that behaves like @Entity and @Embeddable Usually I see something like, don't do this "except in special cases". Is what Im talking about one of these cases. If not, what exactly would be the appropriate case to use this.

Also note that once a Restaurant is put in the database, its representation is immutable. I realize this is unrealistic with the contrived example, but thats the case of my domain. This makes me think that making all the members part of the composite key is the way to go....

Upvotes: 1

Views: 322

Answers (1)

JB Nizet
JB Nizet

Reputation: 691695

Hibernate doesn't use equals and hashCode to know if an entity is already persistent or not. If the entity has an ID, it is persistent. Else, it's new. And two entities are the same if they have the same ID. The equals method is only used to compare two detached entities, or to compare a detached entities with an attached one, in your code (and not in the Hibernate code).

You also need equals and hashCode if the entities are stored in a Set.

If you really need to have an equals and hashCode method, using the collection of children entities to implement them is a very bad idea. Not only do you need to load half of the database to be able to call them, but as soon as you add an ingredient to a dish, its hashCode changes, which "corrupts" the set where it's stored.

You should use a non-nullable immutable unique functional field of the entity to implement equals and hashCode (the restaurant's name, the dish name, the nutrient's name). And definitely use surrogate identifiers. If you don't have such a field, you can use the ID. But just make sure to have it generated before storing the entity in a Set.

Upvotes: 1

Related Questions