Chapter 4. Metadata

Table of Contents

4.1. Dependency Extensions
4.2. Class-level Object-Relational Mapping Extensions
4.3. Field-level Object-Relational Mapping Extensions
4.4. Extensions Under Application Identity
4.5. Examples
4.6. Multi-table Inheritance Mapping
4.7. Generating Default JDO Metadata

Kodo JDO uses standard JDO metadata documents, which are covered in the JDO Overview. Kodo JDO also takes advantage of metadata's built-in extension mechanism to allow you to specify additional information in two categories:

All metadata extensions are optional; Kodo JDO will define its own schema mapping and dependencies by default. If you do choose to specify metadata extension elements, they must have a vendor-name of kodo. The next sections present a list of the available extensions in each category.

4.1. Dependency Extensions

Marking a field as dependent means that when the owning object is deleted, the related object(s) stored in the field will be deleted as well. This process is recursive, so dependent objects can have dependent fields themselves as well. Dependent fields are analyzed during JDO transaction commit.

All dependency-related extensions are specified at the field level (i.e. as direct child elements to the field elements they apply to). They all take a value of true or false:

  • dependent: Setting a value of true for this extension indicates that the persistent object stored in this one-to-one relation field should be deleted when the parent object is deleted.

  • element-dependent: This extension is like the the dependent extension, but applies to the element values of collection fields. Use this extension for one-to-many or many-to-many relations where the related objects should be deleted along with the owning object.

  • value-dependent: This extension is equivalent to the element-dependent extension above, but is used for map values rather than collection elements.

  • key-dependent: This extension applies to map keys. (Note: first class map keys are not yet supported.)