Date: 2005-02-09T14:35:05
Editor: MichelleCaisse
Wiki: Apache JDO Wiki
Page: MetadataMappings
URL: http://wiki.apache.org/jdo/MetadataMappings
no comment
Change Log:
------------------------------------------------------------------------------
@@ -1,38 +1,7 @@
-= <inheritance> =
-
-The Company model provides two inheritance hierarchies: Person <- Employee <-
FullTimeEmployee, PartTimeEmployee; and Insurance <- MedicalInsurance,
DentalInsurance.
-
-There are three inheritance patterns possible:
- *One Table - All rows in the inheritance hierarchy are stored in one table
that has a superset of the required columns plus a discriminator column to
specify the class of that row.
- *Joined Tables (aka Vertical Inheritance) - Each class, including the parent
class, maps to its own table. The tables are joined by their primary keys.
- *Subclass Tables - each subclass maps to a table that contains columns for
both the subclass and its parent class.
-
-The inheritance strategies are mapped by use of the metadata elements
<inheritance> and <discriminator>. The following metadata cases must be tested:
-
-||inheritance pattern||base class||subclasses||
-||One Table|| <inheritance strategy="new-table">|| <inheritance
strategy="superclass-table">||
-||Joined Tables|| <inheritance strategy="new-table">|| <inheritance
strategy="new-table"> <join table="base_class_table" column="fkcolname">*||
-||Subclass Tables|| <inheritance strategy="no-table">|| <inheritance
strategy="new-table">||
-
-'''Question:''' We should test a join on a compound primary key somewhere. It
requires a new model.
-
-When the inheritance pattern is One Table, a <discriminator> element must be
used in the metadata to specify the discriminator strategy and column, used to
distinguish the classes that may be represented in the table.
-||Nested under <inheritance>||Nested under subclass <class> element||
-|| <discriminator value="value-map" column="column_name">|| <discriminator
value="pick_a_value">||
-|| <discriminator value="class-name" column="column_name">||n/a||
-
-When the inheritance pattern is Joined Tables, a <discriminator> element is
optional. It may be used to increase efficiency in some cases.
-
-'''Question:''' What about index element or indexed attribute of
<discriminator>? These are in the dtd, but not mentioned in
Chapter18TestCoverageNotes.
-
-'''Note:''' I think we need some examples for inheritance in Chapter 15.
-
-Combining inheritance pattern with discriminator strategy, there are four
cases that must be tested. Because there are two inheritance hierarchies in
the Company model, we require only two different mappings to cover the four
cases.
-
-= <join> =
-Any class in the Company model could be stored in two tables that are then
joined. However, there are no obvious candidates where this really makes sense
in terms of design. Note that there is also no obvious place to use a compound
primary key in the Company model, so that functionality should be included in
another model.
-= <embedded> =
-Chapter18TestCoverageNotes states that we will test <class embedded-only> in
the Company model Completeness test. I assume that means we will test the case
where embedded-only is true. The simplest case is to embed Address in both
Company and Department. Address is the only class in the Company model that is
neither a subclass nor contains a reference to another class in the model.
+= Default mapping =
+ *DefaultMappingMetadata
+ *DefaultDdl
+= Notes =
== Embedding a subclass ==
The three patterns of inheritance allow for the data of a subclass to be
stored in the superclass table, its own table along with all the fields of the
superclass, or in its own table with only the subclass fields stored. Is it
possible to store a subclass class embedded in another class? What would the
metadata look like?
== Embedding a class holding a reference to another class ==
@@ -75,5 +44,3 @@
...
</class>
If these two types of mappings are possible, they should be tested.
-= Relationships =
-There are many relationships in the Company model that can be mapped as shown
on RelationshipsManyToOne and RelationshipsOneToMany. While these present some
interesting parsing challenges for the implementation, the only
relationship-specific tag to be tested is <element>.
