4 * Composite Key needs to support BelongsTo
\r
6 See NH Docs section 5.1.5. composite-id
\r
9 * Classes that reference a class that uses composite key through relations (and itself) should have the relations columns written to xml automatically. We should not be obligated to specify that explicitly
\r
11 Example from the NHibernate documentation section 7.4:
\r
13 <class name="Foo" table="FOOS">
\r
14 <composite-id name="CompId" class="FooCompositeID">
\r
15 <key-property name="String"/>
\r
16 <key-property name="Short"/>
\r
17 <key-property name="Date" column="date_" type="Date"/>
\r
19 <property name="Name"/>
\r
23 Now, any foreign keys into the table FOOS are also composite. You must declare this in your mappings for other classes. An association to Foo would be declared like this:
\r
25 <many-to-one name="Foo" class="Foo">
\r
26 <!-- the "class" attribute is optional, as usual -->
\r
27 <column name="foo_string"/>
\r
28 <column name="foo_short"/>
\r
29 <column name="foo_date"/>
\r
32 This new <column> tag is also used by multi-column custom types. Actually it is an alternative to the column attribute everywhere. A collection with elements of type Foo would use:
\r
35 <key column="owner_id"/>
\r
36 <many-to-many class="Foo">
\r
37 <column name="foo_string"/>
\r
38 <column name="foo_short"/>
\r
39 <column name="foo_date"/>
\r
43 On the other hand, <one-to-many>, as usual, declares no columns.
\r
45 If Foo itself contains collections, they will also need a composite foreign key.
\r
50 <set name="Dates" lazy="true">
\r
51 <key> <!-- a collection inherits the composite key type -->
\r
52 <column name="foo_string"/>
\r
53 <column name="foo_short"/>
\r
54 <column name="foo_date"/>
\r
56 <element column="foo_date" type="Date"/>
\r
60 * Relations could use a different key than the PK optionally
\r
62 * Shouldnt ARBase<T> have a generic type for the PK? Is it worthwhile?
\r