I have somewhat of a weird case here.

I have a "pseudo" foreign key that always keep it's value even when the parent is deleted. Don't ask, I'm not the one who design it...

I first tried to model the relation as a many-to-one on the child side, but some "missing parents" are causing problems...

I'm now thinking about going to read that parent independentely when ever I need to display the parent information, so that I can handle the "missing parent" manually, instead of specifying it as "many-to-one" relation in NHibernate.

Before I start doing so, since I'm new with NHibernate, I thougt I would post my little problem here to see if that would be the logical way to go. My program won't ever (well, that I know for now) be modifying the parent side (only the child side), I only need to be able to access the parent, when-ever it is available, for display purpose.

So, am I going the right way?

Thank's in advance...

I don't know if it is possible... When loading a child, if the identifier of the <many-to-one> is not null, then NHibernate will try to load it...

How do you know when the value of this "pseudo" foreign key is "valid" (=> linked to a real parent) ? (you trying to load and if it fail, you know it is invalid !?!)

In your database, this "pseudo" foreign key is defined as a classic column; no ? (You will probably end up creating the relation yourself)

It is exactly like you say.

The relation from the child to the parent will always have a non-nul value. But the parent might not be on the other end. If it's not, I'll display the "foreign key value" only, if not, I can display more about it...

So it look like that I'll have to handle this "manually"...