6.8. Custom Class Indicators
Prev | Chapter 6. Standard Features | Next

## 6.8. Custom Class Indicators

By default, Kodo JDO stores the full class name of inserted objects in the database, so that it can determine which type to instantiate when loading data from the database. However, existing databases often have a pre-existing mechanism for storing subclass indicator values. This might be based on a C++ class naming convention, or it might be a numeric indicator. Sometimes, subclass information might not be stored in a single column at all, but might only be determinable by analyzing other values in the result set.

Kodo JDO includes an optional subclass provider that stores integers in the database instead of the full classname. This can be considerably faster than the default provider. To use this alternate provider, set the `com.solarmetric.kodo.impl.jdbc.DefaultSubclassProviderClass` configuration property to `com.solarmetric.kodo.impl.jdbc.ormapping.IntegerSubclassProvider`, and set the `subclass-indicator-value` metadata extension in all your classes to the appropriate integer value. Alternately, this can be performed on a class-by-class basis, by setting the `subclass-provider` metadata extension to `com.solarmetric.kodo.impl.jdbc.ormapping.IntegerSubclassProvider`.

A demonstration: these mappings are specified as demonstrated in the following example, in which rows representing `com.acme.object.Foo` have a value of `1` stored in the `JDOCLASSX` column, and rows representing `com.acme.object.Bar` have a value of `2`:

Example 6.2. IntegerSubclassProvider example

    <jdo>
      <package name="com.acme.object">
        <class name="Foo">
          <!-- specify that we should use this subclass provider instead
            of the default string-based provider for this class. This
            should only be set in the least-derived type in an
            inheritance hierarchy. -->
          <extension vendor-name="kodo" key="subclass-provider"
            value="com.solarmetric.kodo.impl.jdbc.ormapping.IntegerSubclassProvider"/>

          <!-- set up the mapping for this class. This must be done for
            every class in the inheritance hierarchy, and all values
            must be unique. -->
          <extension vendor-name="kodo" key="subclass-indicator-value" value="1"/>
        </class>

        <class name="Bar" persistence-capable-superclass="Foo">
          <!-- set up the mapping for this class. This must be done for
            every class in the inheritance hierarchy, and all values
            must be unique. -->
          <extension vendor-name="kodo" key="subclass-indicator-value" value="2"/>
        </class>
      </package>
    </jdo>

Kodo JDO also supports customization of this default behavior through the `SubclassProvider` interface and the `com.solarmetric.kodo.impl.jdbc.DefaultSubclassProviderClass` configuration property. Additionally, alternate subclass providers can be set on a per-class basis in the JDO metadata. See the Class-level Object-Relational Mapping Extensions documentation for more information on doing this.

Prev | Up | Next
6.7. PersistenceManagerImpl.evictAll() API extensions | Home | 6.9. Storing Second Class Objects via Stringification