ken, thanks for responding. i got things to work, but i haven't figured out really why it's working (on a conceptual, philosophical level). here's what i did to the code above.
1. for the Company class, i removed the @ForeignKey annotation 2. for the Employee class, i removed the companyId field. instead, i used added a Company field. @ManyToOne @JoinColumn(name="companyId") private Company company; 3. for the Employee class, i added @GeneratedValue(strategy=GenerationType.AUTO) to the id field this effectively makes the relationship a bidirectional and 1-N multiplicity for Company and N-1 multiplicity for Employee. one additional thing is that in my code, when you add an Employee to a Company, you have to add the Company to the Employee too. i guess this is what the official JEE 5 tutorial was saying when it said you have to manage the relationship yourself (i had no idea what they were talking about). this JPA approach is quite strange. i don't find it easy at all or intuitive to say the least. even though the JEE 5 and JEE 6 tutorials tell you (in a poor way) about multiplicities and directions, their examples are taken out-of-context. right now, i am having a fun time trying to persist a 1-1 unidirectional relationship. i thought it would be easier, but it is not. what complicates things is that there are many ways to accomplish 1-1 unidirectional relationships (using annotations and the DDL of the actual database). what makes me wildly insane is that a search for "jpa tutorial" returns pages that are too thin or too heavy weight. i wish there was a tutorial on how to get JPA + Hibernate + Spring + Struts2 all working on simple (very simple) examples in different combinations of multiplicity and direction (regarding data persistence). by the way, i got a great response from another post regarding how to do integration unit testing with all these guys (JPA, Hibernate, Spring + Struts2) so now at least i can test data persistence. On Tue, Jun 22, 2010 at 1:38 PM, Ken <ken.mcwilli...@aerose.com> wrote: > I'm sorry I quickly scanned this and didn't read it in full... > > Here is my 2 cents. > > "InnoDB rejects any INSERT or UPDATE operation that attempts to create a > foreign key value in a child table if there is no a matching candidate > key value in the parent table." So the parent has a valid entry before a > row is created in the child? > > I noticed in defining the mysql table you use: > foreign key (companyId) references company(id) > > Which has no ON DELETE or ON UPDATE clauses... so of course the above > becomes: > FOREIGN KEY (jcompanyid) REFERENCES company(id) > ON DELETE RESTRICT > ON UPDATE RESTRICT > > This would prevent you from deleting the parent or changing the foreign > key in the parent if there is a dependant child. I bring this up > because I noticed the use of CascadeType's. > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
