7.11. Orphaned Keys
Prev | Chapter 7. Mapping | Next

## 7.11. Orphaned Keys

Unless you apply database foreign key constraints extensively, it is possible to end up with orphaned keys in your database. For example, suppose `Magazine` `m` has a reference to `Article` `a`. If you delete `a` without nulling `m`'s reference, `m`'s database record will wind up with an orphaned key to the non-existent `a` record.

| Note
One way of avoiding orphaned keys is to use dependent fields.

Kodo's `kodo.OrphanedKeyAction` configuration property controls what action to take when Kodo encounters an orphaned key. You can set this plugin string (see Section 2.5, “Plugin Configuration”) to a custom implementation of the `kodo.event.OrphanedKeyAction` interface, or use one of the built-in options:

- `log`: This is the default setting. This option logs a message for each orphaned key. It is an alias for the `kodo.event.LogOrphanedKeyAction` class, which has the following additional properties:

  - `Channel`: The channel to log to. Defaults to `kodo.Runtime`.

  - `Level`: The level to log at. Defaults to `WARN`.

- `exception`: Throw an exception when Kodo discovers an orphaned key. This is an alias for the `kodo.event.ExceptionOrphanedKeyAction` class.

  In JPA, the exception type will be `javax.persistence.EntityNotFoundException`.

  In JDO, the exception type will be `javax.jdo.JDOObjectNotFoundException`.

- `none`: Ignore orphaned keys. This is an alias for the `kodo.event.NoneOrphanedKeyAction` class.

Example 7.35. Custom Logging Orphaned Keys

JPA XML format:

    <property name="kodo.OrphanedKeyAction" value="log(Channel=Orphans, Level=DEBUG)"/>

JDO properties format:

    kodo.OrphanedKeyAction: log(Channel=Orphans, Level=DEBUG)

Prev | Up | Next
7.10. Custom Mappings | Home | Chapter 8. Deployment