Hello. I have two questions connected to the NHibernte many-to-one associations.

1. I have two classes, the Sensor and the Unit. The Sensor has a Unit type property. If I delete a Unit object, I wanna automatically delete all of the Sensor objects which refered to this instance. But of course, if I delete a Sensor, I wanna keep the Unit, because it is possible, that other Sensors use it. How to do this? Now I have foreign key constraint in the database, which can handle the situation... but the Sensor in the database is stored in two separated tables, because of the table-per-subclass hierarchy, and the database foreign key constraint deletes the data just from one table and the rest is still in the system. I need to handle this by NHibernate and not database.

2. If all of the Sensors which were referering to a Unit was deleted, how can I automatically delete this Unit?

I hope you can help me, or give me some advice to keep continue searching for the solution. Thank you in advance.

To acheive (1), the best way is to map it as a Parent-Child relationship, and set teh cascade on your collection to all or all-delete-orphan. See http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/example-parentchild.html.

I don't know of a way to acheive (2) automatically via NHibernate. That may be something that your framework has to handle. Very easy to write a periodically run sproc that prunes childless parents (or Sensor-less Units).

Unfortunately this article didn't help me. Adding a collection to the Unit side is not a solution for me, at least I wouldn't like to do it, because it doesn't follow my logic: the Unit shouldn't know who uses it, it's not important for it. I am curious if there is any possibility to create the many-to-one association behave like a foreign key, or just the mentioned way is the only way... Is it bad if I leave the foreign key in the database and that solves my problem? Or shell I solve it with Hibernate? Thank you in advance.

Have you looked at using custom SQL for delete (see http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/querysql.html#querysql-cud). It may not be possible to perform two queries in a single <sql-delete> context, but it might be worth taking a look at it.

Even if this does work, I'd still say the other way is better, for two reasons. On the technical side, it may risk an inconsistent session state, since data is being manipulated without NHibernate's "knowledge". This could result in some unpredicatable behavior/errors.

On the semantic side, it seems like you are trying to have your cake and eat it. If the Unit object doesn't "know" about a Sensor, then it shouldn't "care" whether there are Sensors referencing it if it is being deleted. Suppose the two were highly disconnected, residing in two different codebases entirely. Putting this new reference with foreign key in the database suddenly results in a new deletion-blocking behavior for Unit. So, either the Unit knows about its Sensors so they can be deleted with it, or it doesn't (no foreign key) and they have to be actively deleted by some other process. (This may be part of what the Sensor is "sensing," the deletion of its Unit object.) Otherwise, your Unit is like a really bad stage actor that blithely pretends his audience doesn't exist, but upon his dramatic death whispers out of the corner of his mouth, "in case you didn't catch that, I'm dead!"

Returning to reality: if you do include a Sensor collection, it need not be too intrusive on your model. If it is lazy and rarely accessed, it shouldn't be a burden at all. NHibernate can also access private and protected members, so it can be as though the Unit "knows" about it's sensors, but no one else knows it knows.