as i understand it, to correctly implement a bi-directional parent/child relationship in Hibernate you basically have three facets:

1) a collection on the parent with a "one-to-many" mapping element

2) a "many-to-one" element in the child mapping

3) setting "inverse = true" on the collection in the parent, to tell hibernate that the child is managing the association

The Hibernate documentation does a pretty good job explaining implications of step #3 and how its use (or non-use) affects the generated SQL.... but I cant find any explanation about *why* Hibernate chose to implement this way.

Shouldnt steps #1 and #2 be enough to define a bi-directional relationship? As the Hibernate docs explain using many examples, you dont want both ends trying to manage the association in most common usages, so why require it?

In other words, isnt doing step #1 and step #2 above with an inverse="false" mapping considered "exotic" usage? I can see that you *could* do this, but it dont see it as a necessity. Can someone show an example of where this would be required?

TIA,
Mike

Some people use <many-to-one insert="false" update="false"/>

I would say it was done this way to be consistent with the many-to-many bi-dir. And to be consistent wether people set 1 way different from the other


Anyway, do inverse="true" in one way and set the relationship bidir in your code seems not to be *too much* to ask.

You are right, it is not too much to ask :)

Thanks for answering my post. I sort of figured that many-to-many might be an underlying reason.

Hibernate is really good, no question.

But shouldn't a OR-Tool abstract the java business object model (BOM) from the
table model by means of of mapping java classes to tables?

I think "inverse=true" breaks this law and causes the java classes
to be changed only because the foreign key is in the "wrong table"
and could cause DB constraint violations by hibernate.

"inverse=true" forces me to put a n-to-one association method
into my child java class - EVEN IF I DON'T NEED IT.

More worse, I have create jave code to synchronize the links
between the parent and child objects.

I have to introduce the method because hibernate doesn't manage
the passing of the parent PK to the child FK internally.

Pragmatically I have no problem with that, but I am wondering if there are any drawbacks:

- need for additional code to synchronize the links between the parent and child objects
- cyclic references of java class instances could cause the garbage collector
to reserve the memory longer than needed
- the java BOM is poluted by unnecessary "back link properties"
- mapping is more difficult to understand
- ...?

I would suggest that hibernate manages the "inverse list" of
PK-FK-propagation internally without the need for an explicit property in the child java class.

The mapping descriptor needs a new way to recognize the
FK to be used AND the which two "association mappings"
belong together (if an inverse-link from the child to the parent
exists).

This would better reflect the meaning of an "association" in the UML
sense, which is a declaration of a relation between (normally) two
classes. An association can have different directions:
- parent to child (classical unidirectional)
- child to parent ("inverse" in the hibernate sense?)
- parent to child an back (bidirectional)
For each direction I declare a "role name" in UML, which is nothing
else than the property name in java class to manage the association.
So if I have only a unidirectional association I also need only one property (named according to the role name).

I think, the needed java files according to the hibernate mapping for unidirectional 1-n-associations is not consistent to the UML BOM and
should be changed in the long run.

At the moment this is more an aesthetic point.

This has been discussed MANY times before. Everyone forgets that Hibernate objects can be detached and that this fact massively restricts what can be sensibly implemented as far as association management goes. Forget CMR if there is no "container".

(It is really the combination of two things: support for detached objects, and startup-time SQL generation.)

Gavin, I never thought of detached objects before in combination with that problem...

<thinking>

... and I think, you are right, I don't love "inverse=true", but under this aspect,
there seems to be no other simple solution.

Gavin,

I can sort of see why generating the SQL ahead of time would have a bearing on this, but I am not following you on detached objects.

This may be b/c I dont fully understand what you mean by "detached objects" I always thought this was a fancy way of saying that you could tell if an object is persistent by checking identities or versions. Maybe you could help me understand this a little better?

Thanks
-Mike

just have a look at the wiki for a good explanation:

http://www.hibernate.org/168.html

or (shortly said):

"instances loaded from a previous [hibernate] Session are reused in a new Session"...