NHibernate mapping trouble - nhibernate

I have the following object model:
A top-level abstract class Element with many children and descendants.
A class Event.
Each Element contains a bag of Events.
Each Event has a pointer to the parent Element.
Up till now - pretty standart one-to-many relationship.
But, I want to use table per concrete class strategy. So, the class Element is not mapped to the database. I've tried to solve it this way: each of the concrete descendants of Element defines its own Bag of Events. The problem with this is that each <bag> element contains a <key> element. That key points to the Parent property of Event. It also makes the Parent column in the Events table a foreign key to the table which contains the Bag! But one column can't be a foreign key to several tables and I'm getting an exception on insert.
I've also tried to make the Parent field in the Events table a many-to-any kind of field. That worked. But when I want to make the relation bidirectional, meaning, to add the bags to the descendants of Element I come back to the same problem. Bag => foreign key => exception on insert.
I'm sure this case isn't as unique as it seems.
Thank you in advance for your help.

A little bit late, but I have some advise.
If you are using "table per concrete class", it is as if you would map completely independent tables. So you need separate foreign keys or many-to-any.
many-to-any stores the type name and NH knows to where the foreign key points. But it's impossible to have constraints on such a foreign key.
If you have several bags having items of the same type, make sure they all define different foreign keys:
<class name="A">
<!-- ... -->
<bag name="Events">
<key column="A_FK"/>
<one-to-many class="Event"/>
</bag>
</class>
<class name="B">
<!-- ... -->
<bag name="Events">
<key column="B_FK"/>
<one-to-many class="Event"/>
</bag>
</class>
You can have foreign key constraints on such a foreign key, but no not-null constraint, because only one of these foreign keys is used.
To really have only one foreign key with all the constraints, you need to map the element to a separate table.

Related

Unique names in primary keys

I have db tables in each I have same primary column name ('ID')
I get error from nhibernate:
System.IndexOutOfRangeException : An SqlCeParameter with
ParameterIndex '5' is not contained by this SqlCeParameterCollection
When I change these columns names to unique names, all is ok.
But i wonder how to fix it without name changes. I simply want same name in each table.
<class name="AppSignature" table="app_signatures" lazy="true">
<id name="Id"><generator class="guid"></generator></id>
</class>
<class name="AppState" table="app_states" lazy="true">
<id name="Id"><generator class="guid"></generator></id>
<many-to-one name="app_signature"
class="AppSignature"
column="Id"
foreign-key="id_fom_app_signature"
not-null="true"
>
</many-to-one>
</class>
Many-to-one relation means that an AppState instance can be assigned at most to one AppSignature instance. To an AppSignature can be assigned any number of AppState instances. This relation is implemented as an foreign key from app_states table to app_signatures table. "Column" attribute in "many-to-one" element determines column name that stores a value for the foreign key. To the Id column are mapped two AppState members: Id and app_signature which is not possible in NH and leads to the described exception.
The fix is easy:
<many-to-one name="app_signature"
class="AppSignature"
column="app_signature_id"
foreign-key="id_fom_app_signature"
not-null="true"
>
</many-to-one>
Name of column that implements foreign key was changed to an unique name: "app_signature_id". Now app_signature member is mapped to AppState.app_signature_id column which points to the app_signatures.Id column
However described exception should disappear (if the new column is properly added to app_signatures table) it would not necessarily be what you you really want. The relation between AppState and AppSignature could be one-to-one. It means an AppState instnace can be assigned to a single AppSignature instnance and vice versa. Such relation could be implemented by a primary and foreign key on the same column. There is a very nice article about one-to-one relations.

Maintaining multiple one-to-many

Following on from NHibernate one-to-one vs 2 many-to-one
Is there an easy way to maintain multiple one-to-many relationships which are being used as a pseudo one-to-one.
E.g.
If I have 2 entities, User and Contact, which are related by a FK on each (User.ContactId and Contact.UserID).
What is the best way to maintain that each reference points at the other. It would be wrong for the system to update User with a different contact, but the Contact still references User...
Most likely you don't need to maintain this at all if you remove one of redundant foreign keys. Your database schema should not allow anomalies like that (userX references contactX but contactX references userY). Conceptually you have one-to-one relationship between user and contact. Why not have one-to-one in NHibernate mappings? If this is because of lazy loading that is not supported for nullable one-to-one in NHibernate? There is a solution to this problem that does not involve redundant foreign keys in the database.
1) In User mapping define a bogus list. List can have only one or zero items. Zero is treated as NULL (no Contact).
<bag
name="_contact"
table="UserContacts"
lazy="true"
inverse="true"
cascade="all-delete-orphan" >
<key column="UserId" />
<one-to-many class="Contact" />
</bag>
In Contact mapping define one-to-one:
<one-to-one name="_user" class="User" constrained="true" />
In the database you need to have PK Users.Id and one (!) foreign key Contacts.UserID.
2) Another option is to simply have many-to-one in User mapping and one FK Users.ContactId
<many-to-one
name="_contact"
column="ContactId"
cascade="all-delete-orphan"
unique="true"
lazy="proxy"/>
Either way the maintenance that you asked about is not needed and anomalies are not possible.

How to map many to many association in NHibernate

I have some database tables named Project, Employee and Branch. An employee can work simultaneously on more than one project. Similarly, in a project, there are multiple employees. Also, a project is conducted at a particular branch. To maintain all these relationships, I am using a project_employee_branch table, which will store the related primary keys of the above three tables. As an example, this project_employee_branch table may contain a row like (1,2,3), which means the project whose primary key is 1, is conducted at branch whose primary key is 3, and one of its project member is an employee whose primary key is 2.
How can I map all these associations in NHibernate? I have mapped many-to-one association using foreign key concept, but I don't know how to map these types of associations, where an intermediate table is involved.
First point I'd make is that your database schema and your description don't match, so please take any advice below in the light of that initial caveat. You say that
a project is conducted at a particular branch
which implies there should be a simple foreign key relationship from project to branch. And of course, if this is what the schema looked like, you would have a two-way many-to-many link table and your life would be much easier.
Anyway, with the three-way combination you have, you need to have a collection of components, where the components have many-to-one properties for the other two object types. There is an example in section 7.2 of the NHibernate documentation, but I think it would look something like this in the mapping for Product:
<set name="BranchEmployees" table="product_employee_branch" lazy="true">
<key column="product_id">
<composite-element class="Purchase">
<many-to-one name="Branch" class="Branch" />
<many-to-one name="Employee" class="Employee"/>
</composite-element>
</set>

When to use inverse=false on NHibernate / Hibernate OneToMany relationships?

I have been trying to get to grips with Hibernate's inverse attribute, and it seems to be just one of those things that is conceptually difficult.
The gist that I get is that when you have a parent entity (e.g. Parent) that has a collection of Child objects using a one-to-many mapping, setting inverse=true on the mapping tells Hibernate that 'the other side (the Child) has responsibility to update itself to maintain the foreign key reference in its table'.
Doing this appears to have 2 benefits when it comes to adding Children to the collection in your code, and then saving the Parent (with cascade-all set): you save an unneccessary hit on the database (because without inverse set, Hibernate thinks it has two places to update the FK relationship), and according to the official docs:
If the column of a
association is declared
NOT NULL, NHibernate may cause
constraint violations when it creates
or updates the association. To prevent
this problem, you must use a
bidirectional association with the
many valued end (the set or bag)
marked as inverse="true".
This all seems to make sense so far. What I don't get is this: when would you NOT want to use inverse=true on a one-to-many relationship?
As Matthieu says, the only case where you wouldn't want to set inverse = true is where it does not make sense for the child to be responsible for updating itself, such as in the case where the child has no knowledge of its parent.
Lets try a real world, and not at all contrived example:
<class name="SpyMaster" table="SpyMaster" lazy="true">
<id name="Id">
<generator class="identity"/>
</id>
<property name="Name"/>
<set name="Spies" table="Spy" cascade="save-update">
<key column="SpyMasterId"/>
<one-to-many class="Spy"/>
</set>
</class>
<class name="Spy" table="Spy" lazy="true">
<id name="Id">
<generator class="identity"/>
</id>
<property name="Name"/>
</class>
Spymasters can have spies, but spies never know who their spymaster is, because we have not included the many-to-one relationship in the spy class. Also (conveniently) a spy may turn rogue and so does not need to be associated with a spymaster. We can create entities as follows:
var sm = new SpyMaster
{
Name = "Head of Operation Treadstone"
};
sm.Spies.Add(new Spy
{
Name = "Bourne",
//SpyMaster = sm // Can't do this
});
session.Save(sm);
In such a case you would set the FK column to be nullable because the act of saving sm would insert into the SpyMaster table and the Spy table, and only after that would it then update the Spy table to set the FK. In this case, if we were to set inverse = true, the FK would never get updated.
Despite of the high-voted accepted answer, I have another answer to that.
Consider a class diagram with these relations:
Parent => list of Items
Item => Parent
Nobody ever said, that the Item => Parent relation is redundant to the Parent => Items relation. An Item could reference any Parent.
But in your application, you know that the relations are redundant. You know that the relations don't need to be stored separately in the database. So you decide to store it in a single foreign key, pointing from the Item to the Parent. This minimal information is enough to build up the list and the reference back.
All you need to do to map this with NH is:
use the same foreign key for both relations
tell NH that one (the list) is redundant to the other and could be ignored when storing the object. (That is what NH actually does with inverse="true")
These are the thoughts which are relevant for inverse. Nothing else. It is not a choice, there is only one way of correct mapping.
The Spy Problem:
It is a completely different discussion if you want to support a reference from the Item to the Parent. This is up to your business model, NH doesn't take any decisions in this. If one of the relations is missing, there is of course no redundancy and no use of inverse.
Misuse: If you use inverse="true" on a list which doesn't have any redundancy in memory, it just doesn't get stored. If you don't specify the inverse="true" if it should be there, NH may store the redundant information twice.
If you want to have an unidirectional association i.e. that the children can't navigate to the Parent. If so, you FK column should be NULLABLE because the children will be saved before the parent.

NHibernate multiple primary keys mapping

I have a table called "Orderrow". Orderrow has a a compound primary key (CPK) with the following columns: OrderId, ProductId, RowNumber
OrderId and ProductId are also foreign keys refering to the tables Order and Product. The RowNumber is generated in the app.
I was wondering how this is mapped in NHibernate because I can only set 1 id element and 1 generator subelement.
Here is an example using the composite-id property in a NHibernate mapping file:
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Domain" namespace="Domain.Model">
<class name="Program" table="program">
<composite-id>
<key-property name="Id" column="id"></key-property>
<key-property name="Prog" column="prog"></key-property>
<key-property name="Site" column="site"></key-property>
</composite-id>
<property name="ActiveDate" column="active_date"/>
<property name="Year" column="year"/>
</class>
</hibernate-mapping>
There is a 'composite-id' property you can use in your class mapping instead of the 'id' property. However, you should know that the nHibernate team strongly discourages the use of it. It sounds like you are dealing with a legacy database, in which you have no control over the schema. So, the 'composite-id' is specifically for your situation.
Check out the NH docs for more info: http://nhibernate.info/doc/nh/en/index.html
Personally I do not like to have compound primary keys in my database table schemas, plus they usually are 'hard' to handle by any ORM mapper I tried.
If I have to give a unique identity to a row in a table (especially if it represents a business object), I prefer to use a single value surrogate Id - a GUID or an Integer - if any of the fields in the table isn't suitable.
Using a composite Id is always troublesome when writing interrogation queries and joins, so my usual strategy is to use a surrogate Id (which has no meaning to the business object but to identify the object itself) and place a unique constraint on the fields of the previous CPK.