-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO.txt
65 lines (47 loc) · 2.07 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
For RC 2
========
* Composite Key needs to support BelongsTo
See NH Docs section 5.1.5. composite-id
* 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
Example from the NHibernate documentation section 7.4:
<class name="Foo" table="FOOS">
<composite-id name="CompId" class="FooCompositeID">
<key-property name="String"/>
<key-property name="Short"/>
<key-property name="Date" column="date_" type="Date"/>
</composite-id>
<property name="Name"/>
....
</class>
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:
<many-to-one name="Foo" class="Foo">
<!-- the "class" attribute is optional, as usual -->
<column name="foo_string"/>
<column name="foo_short"/>
<column name="foo_date"/>
</many-to-one>
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:
<set name="Foos">
<key column="owner_id"/>
<many-to-many class="Foo">
<column name="foo_string"/>
<column name="foo_short"/>
<column name="foo_date"/>
</many-to-many>
</set>
On the other hand, <one-to-many>, as usual, declares no columns.
If Foo itself contains collections, they will also need a composite foreign key.
<class name="Foo">
....
....
<set name="Dates" lazy="true">
<key> <!-- a collection inherits the composite key type -->
<column name="foo_string"/>
<column name="foo_short"/>
<column name="foo_date"/>
</key>
<element column="foo_date" type="Date"/>
</set>
</class>
* Relations could use a different key than the PK optionally
* Shouldnt ARBase<T> have a generic type for the PK? Is it worthwhile?