8.2. Custom data requests
Prev | Chapter 8. Additional Features | Next

## 8.2. Custom data requests

The custom data processing feature described above is useful when loading data from externally obtained data feeds, but often, this is only half of the story. Once that data is initially loaded, requests to reload all or part of a particular object may be made by the Kodo JDO runtime framework. Additionally, requests to insert, update or delete data may be issued.

Kodo JDO often makes requests to the JDBC subsystem to find information about a particular object. For example, when a user invokes `PersistenceManager.getObjectById`, Kodo JDO will make a request to the JDBC subsystem to load that particular object. Similarly, Kodo JDO will occasionally make a request to see if a particular object exists in the data store, or if the optimistic lock version information indicates an optimistic lock violation. To intercept these calls and provide custom logic to load the data, extend `com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping` and override the appropriate methods. Following is a brief discussion of some commonly overridden APIs in `ClassMapping`.

- `insert`: Responsible for storing a new persistence-capable instance in the data store.

- `update`: Responsible for updating the data store with the dirty fields in the given `StateManagerImpl`.

- `delete`: Responsible for removing the given `StateManagerImpl` from the database.

- `newExtent`: Responsible for creating a new `Extent` capable of iterating through all objects of the type managed by the `ClassMapping`.

- `loadByPK`: Responsible for selecting and loading the requested data into the provided `StateManagerImpl`.

  Note that the default relation mappings (one-one, one-many, many-many, and n-many) do not necessarily invoke `loadByPk`. Instead, they directly load data from result sets. So, if data must be loaded purely through non-standard means, special care must be taken when loading these types of relations. (One-one relations may be loaded via calls to `loadByPk` if the foreign key information is loaded at initialization time.)

- `checkVersion`: Determines if another thread has modified the data represented by the given `StateManagerImpl`. This is used when determining if an optimistic lock exception should be thrown.

- `exists`: Invoked to check if the given `StateManagerImpl` exists in the data store.

Alternate `ClassMapping` implementations can be specified on a system-wide basis using the `DefaultClassMappingClass` property, or on a per-class basis with the `custom-mapping` metadata extension.

Prev | Up | Next
Chapter 8. Additional Features | Home | Chapter 9. Third Party Integration Features