I want to raise up a question regarding unidirectional and bidirectional associations.
From my point of view it's always better to favor unidirectional associations because bidirectional seems to be excessive and classes wired by bidirectional associations are more cohesive.
How do you think, am I right? To my mind even if bidirectional associations are needed to simplify HQL queries it is better to avoid it thus it can complicate the architecture.
What do you think about it?
You consideration seems concerned only with implementation of the relationship itself.
The most important thing is that these things model relationships existing somewhere, and if the relationship being modeled is truly bidirectional, it will be much easier to program around a model which represents that relationship such.
As an example 2 unidirectional relationships instead of one bidirectional permits for one of these relationships point back at the wrong element:
A --> B --> C
... while B should be pointing back at A:
A <==> B
Related
I am learning persistence with Hibernate (and JPA) on Udemy and the presenter explains an alternative to the previous associations discussed (unidirectional OneToOne, bidirectional OneToOne, Unidirectional OneToMany, bidirectional OneToMany), called the #JoinTable JPA annotation.
He mentions that sometimes only a small selection of the "Many" entities are associated with a specific kind of "One" entities and that we don't want a field on the "Many" entity to embody the association with the "One" entity since that field will remain null for most instances. He goes on to recommend the #JoinTable for this situation.
My question is, considering the effect of the #JoinTable option on the Java entities, why not just use the Unidirectional #OneToMany annotation on the "One" entity and leave the "Many" entity as-is? Which additional features would #JoinTable bring to the situation from within Java beyond what Unidirectional #OneToMany brings?
Then he is clearly wrong, #JoinTable is definitely not necessary here and will introduce overhead in terms of memory (more data to store) and time complexity (another table to join).
You're right about that you only need #JoinColumn to map one-to-one and one-to-many relationships (and mappedBy on the other side if it should be bidirectional).
P.S.: I would consider going further with this course, as it seems to be flawed even with the very basics of jpa.
Lets say I Have two entities with a one to one relationship, a person entity and a person detail entity. Are there any advantages to using cascade when I want to save as oppose to making a separate save for each entity?
Would it be different if it was not a one to one relationship?
To get started, one difference would be, if NOT cascade, there will be multiple network calls (N+1 effect). Based on size data, there are lot of other implications you need to worry about too.
in my code, I have an Employee and Task entities, related with ManyToMany relation. When creating new Employee object, I can assign him to existing tasks with empToBePersisted.getTasks().add(existingTask). However, when I persist it, the relation is persisted in databse but only seen from the Employee side. The Task sees it after restarting the app. How can I make it visible immediately after persisting?
Described behaviour is normal. You need to handle both sides when working with bidirectional associations.
Bidirectional relationships between managed entities will be persisted
based on references held by the owning side of the relationship. It is
the developer’s responsibility to keep the in-memory references held
on the owning side and those held on the inverse side consistent with
each other when they change.
In this case, you will need to call existingTask.setEmployee(empToBePersisted) manually.
You can also see this answer for more details.
I am using JPA to persist my entities. Suppose I have a ManyToMany relationship between the entity A and B. So, in the class A it will be a List<B> and in B a List<A>.
My question is about the efficiency of adding a new relationship.
In the easy way I can make a add(new B()) in the list in class A. Will this List of B objects in the class A will all be loaded from the database when I call the add method in runtime? Is this efficient?
If I have 200 relationships, it will load all of them, to simply add a new object B? It will be better to create a native query to insert a new row the ManyToMany table.
The behavior of add() on a List is dependent on the JPA provider.
For EclipseLink, for a LAZY List relationship add() will not cause the list to be fetched by default.
Usually, JPA providers provide their own implementations of Java Collections which support lazy loading, so not all relationships will be loaded right from the start.
Also, when you modify any of the lists as you described, the JPA provider should transparently update the database. You don't have to worry to keep things consistent, other than references you might have cached on your own.
When it starts to run into the hundreds you might be better off to just map the join table as a JPA entity and not use a ManyToMany mapping but simply perform operations (mutations and selections) directly on the join table with two ManyToOne mappings in there.
I checked
Hibernate 'Inverse' in mapping file and http://www.nhforge.org/doc/nh/en/#collections-bidirectional and http://blog.xebia.com/2009/03/16/jpa-implementation-patterns-bidirectional-assocations/
Do i always have to use inverse=true for the bidirectional mappings on the set (parent) side?
What are the alternatives? Is it also possible to define both sides not-null and not updateable?
if you have a bidirectional mapping then it causes harm to not have one side inversed because if you have Cascade.All both sides would try to maintain the association meaning duplicate entries in link tables or redundant Updates.
Both sides as not updateable is useful for readonly associations.