[Steve Olson]

I’ve run into a weird issue with the generated @JoinColumn tags when reverse engineering tables with conventional composite keys and a foreign key constraint for a standard one-to-many relation. The @JoinColumn tags are generated without using the referencedColumnName tag, which in certain situations for me has resulted in mismatched bind variables and a failure to fetch child rows that should have been. This is fixed every time by supplying explicit referenecedColumnName tags.

Shouldn’t these be generated explicitly just to be safe, instead of letting them default and relying on the underlying impl (Hibernate in my case) to guess right? It seems that hibernate mostly does guess right, but I’ve hit multiple cases now where it doesn’t.

Is there a template somewhere that’s being used for JoinColumn, something that I can edit?

Let me know if this makes sense, or if I need to provide more info. I have lots of available detail if interested, it took me quite a while to determine what was wrong, and I collected alot of info during the research.

For now any time I have a composite key, I’m adding these tags manually to the generated code so to not take this risk, and that’s obviously not the best setup…

Thanks in advance for any help.

[Loyal Water]

Let me know if this makes sense, or if I need to provide more info. I have lots of available detail if interested, it took me quite a while to determine what was wrong, and I collected alot of info during the research.

Could you please give me some more details about this issue. Can you list down the steps to help me reproduce it.

[Steve Olson]

Sorry I haven’t checked back lately on this. Keep in mind if you want to recreate the situation that requires the referencedColumnName tags, you’re digging into a JPA/Hibernate issue, not a Myeclipse one. My point above was that if Myeclipse specified the referencedColumnName tag by default during reverse engineer instead of relying on the underlying JPA stuff to determine the correct default, then issues like this in the JPA layer wouldn’t matter.

Reproducing is a challenge. Here’s one (not the only) scenario that seemed to cause it for us:

A) Define a parent table with a key (Long, String)
B) Define a child table with a three-column composite key (Long, String, String) and some other non-key columns. Define a foreign key constraint on the first two back to the parent.
C) Reverse engineer, and all should work fine.
D) Change the second column from type String (VARCHAR) to Long (NUMBER) on both parent and child tables in the database (ours was oracle) and redo reverse engineer.
E) Use EAGER fetch on the parent and see if JPA retreives child rows correctly. In our case it ended up joining parent col1 values up with child col2, and parent col2 values up with col1, resulting in no rows fetched.

If it helps, I’d skip trying to reproduce this, and consider this question instead: Does it hurt for the JPA reverse engineer to always specify the referenced column names when generating @JoinColumn tags? I can think of no drawback to making these explicit, and if they are there’s no need to rely on the JPA provider and underlying database defaulting in the expected way. If it doesn’t hurt, then why not just do it?

[Sean Parsons]

I have also been fighting this for 3 days. I finally posted a huge entry on the hibernate forums to just find out what is going on..how simple it turned out to be…

However, ME is not adding referencedColumnName where there are multiple @JoinColumn entries on a getter method. If it does not have it…then the mapping will be in some order that might not match the query’s parameter order.

Here is a full blown breakdown of what I wrote…

http://forum.hibernate.org/viewtopic.php?t=986444&highlight=referencedcolumnname

This needs to be fixed ASAP, as I would consider this a major bug. If you don’t know about the referencedColumn requirement, people will be wasting days trying to figure this out, unless you have some hibernate serious JPA experience.

[Riyad Kalla]

Sean,
I’m sending this back to the Persistence team to evaluate immediately, thank you for a detailed run-down.

[Sean Parsons]

sorry: wrong post

http://forum.hibernate.org/viewtopic.php?t=988103

[Author]

Posts