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.