Sorry, it seems like I didn't express myself clear enough....
What I meant is that when you use the con_id in your Category for your relation AND as a normal column you have to set the relation to insertable=false, updateable=false....
If you don't define it as a column you have to remove the insertable=false, updateable=false or you won't be able to persist such a relation...
A simple example...
Let's propose I have two tables, Language and Translation....
Language should have the columns ID and NAME, Translation should have ID, TEXT_ENGLISH, TEXT_TRANSLATED and the foreign key column LANG_ID
Of course each Translation has a Language and - just to make it bidirectional - every Language should have its List of Translations...
Now we could define this as
or you could write
I hope it doesn't confuse you that I annotate the attributes, not the getters..
Doesn't make a difference, just avoid mixing this - at least for style reasons...
And, yes, the second example could cause you trouble, someone could try to set the language (or the consumer in your example), merge the entity and wonder why in the DB the column lang_id is empty... - I told you I would use the first one..
Just a short aditional warning: relations are not container managed in EJB3 - I think it's the same in Hibernate - this means you have to write
If you don't do the second set.. then the langEspanol wouldn't know that it know has one more translation...
Now let's have a look at the relation definition... You said you want to have your con_id in table Category to point to con_id in Consumer instead of the primary key...
Even if I won't do this (for instance for performance reasons, the PK is inndexed, while your con_id may not be indexed) this can be defined using an additional parameter on Annotation @JoinColumn: referencedColumnName
If you don't use the referencedColumnName attribute it will connect to the pk column...
Hopes this answers some of your questions..
Have a nice weekend!
John