I think it does not, it would do so only in case of bidirectional relationship, which is not the case here.But the first part of your example i.e. @OneToOne also implies that in this relationship a Department has one employee, which is not given in the problem statement.
12 posts • Page 1 of 1
- Posts: 185
- Joined: Mon Jun 20, 2016 5:06 pm
- Posts: 125
- Joined: Thu Jul 05, 2018 6:44 pm
The reason (I think) why this is wrong is that it makes the mistake of seeing each part of an integral whole ("An employee can work in only one department and a Department can have any number of Employees") as a part in and of itself, and it sees each such part as corresponding to the/a mapping annotation on one side. Or put more simply, it sees 2 requirements and not one.johnlong wrote: ↑Sat Dec 24, 2016 6:11 pmOk, I will try to explain my point :
Code: Select all
@Entity public class Employee @OneToOne // Requirement 1 of 2 is fulfilled "An employee can work in only one department" private Department DepartmentThose are two unidirectional associations (Problem does not say that it has to be bidirectional relationship)
Code: Select all
@Entity public class Department @OneToMany // Requirement 2 of 2 is fulfilled "Department can have any number of Employees" private Collection<Employee> employees
Saying "An employee can work in only one department and a Department can have any number of Employees" is the same as saying, there is a one-to-many from dept to emp. This is one relationship. It's not two relationships. It's expressed in an ERD with a particular notation. It's expression in OO modelling with a particular notation. It's expressed in ORM in JPA in one of two ways, depending on whether it is unidirectional, bidirectional, or two unidirectionals; if unidirectional, there is either an @OneToMany or @ManyToOne, if bidirectional, you have both, with the many side having mappedBy; if there are 2 unidirectional then you ahve both without mappedBy.
Also note that it says this in ProJPA2:
The JPA annotations were designed to be readable, easy to specify, and flexible enough to allow different combinations of metadata...As with all trade-offs, the piper must be paid however, and the cost of flexibility is that many possible permutations of top-level metadata will be syntactically correct but semantically invalid. The compiler will be of no use, but the provider runtime will often do some basic checking for improper annotation groupings. The nature of annotations, however, is that when they are unexpected, they will often just not get noticed at all. This is worth remembering when attempting to understand behavior that might not match what you thought you specified in the annotations. It could be that one or more of the annotations are being ignored.
Users browsing this forum: No registered users and 1 guest