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.