I know that in many-to-many bidirectional association are owner and dependent entity.
What do I know about owner and dependent for writing my application?
What differencies are between them?
According to docs:
The direction of a relationship can be either bidirectional or unidirectional. A bidirectional relationship has both an owning side and an inverse side. A unidirectional relationship has only an owning side. The owning side of a relationship determines how the Persistence runtime makes updates to the relationship in the database.
I think about about owning side as "main" side of the relation. Entity on this side defines most of the properties of the relation and it's state is used to "control" relation.
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.
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
I am confused in owner in relationship with hibernate.
what exactly is owner(owner side) in association?
I want to study Mappedby and inverse.
please help.
As a general rule the owning side of a relation would the side which you'd need to update for the change of the relation to be persisted.
If you are mapping the entities to a relational database (most probably the case) the owning side often can be identified as the entity whose table contains the foreign key.
In the entities themselves mappedBy would refer to the owning side and thus is placed on the inverse side of the relation.
In 1:n relations in most cases the owning side is the n side, in n:m relations, 1:1 relations or 1:n with mapping tables you can choose either side, just choose one.
Example:
class Thread {
#OneToMany( mappedBy = "thread" )
List<Entry> entries;
}
class Entry {
#ManyToOne
Thread thread;
}
In the example, the owning side would be the Entry entity, since you need to change the value of Entry#thread to change the thread an entry belongs to. Just adding/removing an entry to/from Thread#entries wouldn't make the changes persisted in most cases (orphanRemoval and the like would still have an effect if done correctly).
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 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.