Section 5.3, “Object Identity” describes how to use datastore identity in JPA. Kodo requires a single numeric primary key column to hold datastore identity values. The org.apache.openjpa.persistence.jdbc.DataStoreIdColumn annotation customizes the datastore identity column. This annotation has the following properties:

All properties correspond exactly to the same-named properties on the standard Column annotation, described in Section 12.3, “Column”.

import org.apache.openjpa.persistence.*;
import org.apache.openjpa.persistence.jdbc.*;

@Entity
@Table(name="LOGS")
@DataStoreIdColumn(name="ENTRY")
public class LogEntry
{
    @Lob
    private String content;

    ...
}

Kodo supports version fields as defined by the JPA specification, but allows you to use a surrogate version column in place of a version field if you like. You map the surrogate version column with the kodo.persistence.jdbc.LockGroupVersionColumn annotation. If you take advantage of Kodo's ability to define multiple lock groups, you may have multiple version columns. In that case, use the kodo.persistence.jdbc.LockGroupVersionColumns annotation to declare an array of LockGroupVersionColumn values. Each LockGroupVersionColumn has the following properties:

The lockGroup property allows you to specify that a version column is for some lock group other than the default group. See Section 5.8, “Lock Groups” for an example. All other properties correspond exactly to the same-named properties on the standard Column annotation, described in Section 12.3, “Column”.

By default, Kodo assumes that surrogate versioning uses a version number strategy. You can choose a different strategy with the VersionStrategy annotation described in Section 7.9.1.4, “Version Strategy”.

Kodo makes it easy to create multi-column custom mappings. The JPA specification includes a Column annotation, but is missing a way to declare multiple columns for a single field. Kodo remedies this with the org.apache.openjpa.persistence.jdbc.Columns annotation, which contains an array of Column values. Example 7.34, “Custom Mappings via Extensions” uses Kodo's Columns annotation to map a java.awt.Point to separate X and Y columns.

Remember to annotate custom field types with Persistent, as described in Section 6.3.3, “Persistent Field Values”.

Section 12.8.4, “Direct Relations” in the JPA Overview introduced you to the JoinColumn annotation. A JoinColumn's referencedColumnName property declares which column in the table of the related type this join column links to. Suppose, however, that the related type is unmapped, or that it is part of a table-per-class inheritance hierarchy. Each subclass that might be assigned to the field could reside in a different table, and could use entirely different names for its primary key columns. It becomes impossible to supply a single referencedColumnName that works for all subclasses.

Kodo rectifies this by allowing you to declare which attribute in the related type each join column links to, rather than which column. If the attribute is mapped differently in various subclass tables, Kodo automatically forms the proper join for the subclass record at hand. The org.apache.openjpa.persistence.jdbc.XJoinColumn annotation has all the same properties as the standard JoinColumn annotation, but adds an additional referencedAttributeName property for this purpose. Simply use a XJoinColumn in place of a JoinColumn whenever you need to access this added functionality.

For compound keys, use the org.apache.openjpa.persistence.jdbc.XJoinColumns annotation. The value of this annotation is an array of individual XJoinColumns.

JPA uses the AttributeOverride annotation to override the default mappings of an embeddable class. The JPA Overview details this process in Section 12.8.3, “Embedded Mapping”. AttributeOverrides suffice for simple mappings, but do not allow you to override complex mappings. Also, JPA has no way to differentitate between a null embedded object and one with default values for all of its fields.

Kodo overcomes these shortcomings with the kodo.persistence.jdbc.XEmbeddedMapping annotation. This annotation has the following properties:

The XEmbeddedMapping's overrides array serves the same purpose as standard JPA's AttributeOverrides and AssociationOverrides. In fact, you can also use the XMappingOverride annotation on an entity class to override a complex mapping of its mapped superclass, just as you can with AttributeOverride and AssociationOverrides. The XMappingOverrides annotation, whose value is an array of XMappingOverrides, allows you to overide multiple mapped superclass mappings.

Each kodo.persistence.jdbc.XMappingOverride annotation has the following properties:

The following example defines an embeddable PathCoordinate class with a custom mapping of a java.awt.Point field to two columns. It then defines an entity which embeds a PointCoordinate and overrides the default mapping for the point field. The entity also declares that if the PathCoordinate's siteName field column is null, it means that no PathCoordinate is stored in the embedded record; the owning field will load as null.

import kodo.persistence.jdbc.*;
import org.apache.openjpa.jdbc.persistence.jdbc.*;

@Embeddable
public class PathCoordinate
{
    private String siteName;

    @Persistent
    @Strategy("com.xyz.kodo.PointValueHandler")
    private Point point;

    ...
}

@Entity
public class Path
{
    @Embedded
    @XEmbeddedMapping(nullIndicatorFieldName="siteName", overrides={
        @XMappingOverride(name="siteName", columns=@Column(name="START_SITE")),
        @XMappingOverride(name="point", columns={
            @Column(name="START_X"),
            @Column(name="START_Y")
        })
    })
    private PathCoordinate start;

    ...
}

In Section 6.3.4, “Persistent Collection Fields”, we explored the PersistentCollection annotation for persistent collection fields that aren't a standard OneToMany or ManyToMany relation. To map these non-standard collections, combine Kodo's ContainerTable annotation with ElementColumns, ElementJoinColumns, or an ElementEmbeddedMapping. We explore the annotations below.

7.7.6.6. Examples

Our first example maps the Article.subtitles field to the ART_SUBS container table, as shown in the diagram above. Notice the use of ContainerTable in combination with ElementColumn and OrderColumn to map this ordered list of strings.

Example 7.29. String List Mapping

package org.mag;

import kodo.persistence.jdbc.*;
import org.apache.openjpa.persistence.*;
import org.apache.openjpa.persistence.jdbc.*;

@Entity
@Table(name="ART")
public class Article
{
    @Id private long id;

    @PersistentCollection
    @ContainerTable(name="ART_SUBS", joinColumns=@XJoinColumn(name="ART_ID"))
    @ElementColumn(name="SUBTITLE")
    @OrderColumn(name="ORD")
    private List<String> subtitles;

    ...
}

Now we map a collection of embedded Address objects for a Company, according to the following diagram:

Example 7.30. Embedded Element Mapping

package org.mag.pub;

import kodo.persistence.jdbc.*;
import org.apache.openjpa.persistence.*;
import org.apache.openjpa.persistence.jdbc.*;

@Embeddable
public class Address
{
    ...
}

@Entity
@Table(name="COMP")
public class Company
{
    @Id private long id;
  
    @PersistentCollection(elementEmbedded=true)
    @ContainerTable(name="COMP_ADDRS", joinColumns=@XJoinColumn(name="COMP_ID"))
    @ElementEmbeddedMapping(overrides=@XMappingOverride(name="state", 
        columns=@Column(columnDefinition="CHAR(2)")))
    private Collection<Address> addresses;

    ...
}

The previous section covered the use of ElementJoinColumn annotations in conjunction with a ContainerTable for mapping collections to dedicate tables. ElementJoinColumns, however, have one additional use: to create a one-sided one-many mapping. Standard JPA supports OneToMany fields without a mappedBy inverse, but only by mapping these fields to a JoinTable (see Section 12.8.5, “Join Table” in the JPA Overview for details). Often, you'd like to create a one-many association based on an inverse foreign key (logical or actual) in the table of the related type.

Consider the model above. Subscription has a collection of LineItems, but LineItem has no inverse relation to Subscription. To retrieve all of the LineItem records for a Subscription, we join the SUB_ID inverse foreign key column in the LINE_ITEM table to the primary key column of the SUB table. The example below shows how to represent this model in mapping annotations. Note that Kodo automatically assumes an inverse foreign key mapping when element join columns are given, but no container or join table is given.

package org.mag.subscribe;

import org.apache.openjpa.persistence.jdbc.*;

@Entity
@Table(name="LINE_ITEM", schema="CNTRCT")
public class LineItem
{
    ...
}

@Entity
@Table(name="SUB", schema="CNTRCT")
public class Subscription
{
    @Id private long id;

    @OneToMany
    @ElementJoinColumn(name="SUB_ID", target="ID")
    private Collection<LineItem> items;

    ...
}

Section 6.3.5, “Persistent Map Fields” discussed the PersistentMap annotation for persistent map fields. To map these non-standard fields to the database, combine Kodo's ContainerTable annotation with KeyColumns, KeyJoinColumns, or an KeyEmbeddedMapping and ElementColumns, ElementJoinColumns, or an ElementEmbeddedMapping.

We detailed the ContainerTable annotation in Section 7.7.6.1, “Container Table”. We also discussed element columns, join columns, and embedded mappings in Section 7.7.6.2, “Element Columns”, Section 7.7.6.3, “Element Join Columns”, and Section 7.7.6.4, “Element Embedded Mapping”. Key columns, join columns, and embedded mappings are new, however; we tackle them below.

7.7.8.4. Examples

Map mapping in Kodo uses the same principles you saw in collection mapping. The example below maps the Article.authors map according to the diagram above.

Example 7.32. String Key, Entity Value Map Mapping

package org.mag.pub;

import kodo.persistence.jdbc.*;
import org.apache.openjpa.persistence.*;
import org.apache.openjpa.persistence.jdbc.*;

@Entity
@Table(name="AUTH")
@DataStoreIdColumn(name="AID" columnDefinition="INTEGER64")
public class Author
{
    ...
}

package org.mag;

@Entity
@Table(name="ART")
public class Article
{
    @Id private long id;
 
    @PersistentMap
    @ContainerTable(name="ART_AUTHS", joinColumns=@XJoinColumn(name="ART_ID"))
    @KeyColumn(name="LNAME")
    @ElementJoinColumn(name="AUTH_ID")
    private Map<String,Author> authors;

    ...
}

Kodo uses index information during schema generation to index the proper columns. Kodo uses foreign key and unique constraint information during schema creation to generate the proper database constraints, and also at runtime to order SQL statements to avoid constraint violations while maximizing SQL batch size.

Kodo assumes certain columns have indexes or constraints based on your mapping defaults, as detailed in Section 7.4, “Mapping Defaults”. You can override the configured defaults on individual joins, field values, collection elements, map keys, or map values using the annotations presented in the following sections.

7.7.9.4. Examples

Here again is our map example from Section 7.7.8, “Maps”, now with explicit indexes and constraints added.

Example 7.33. Constraint Mapping

package org.mag.pub;

import kodo.persistence.jdbc.*;
import org.apache.openjpa.persistence.*;
import org.apache.openjpa.persistence.jdbc.*;

@Entity
@Table(name="AUTH")
@DataStoreIdColumn(name="AID" columnDefinition="INTEGER64")
public class Author
{
    ...
}

package org.mag;

@Entity
@Table(name="ART")
public class Article
{
    @Id private long id;
 
    @PersistentMap
    @ContainerTable(name="ART_AUTHS", joinColumns=@XJoinColumn(name="ART_ID")
        joinForeignKey=@ForeignKey(deleteAction=ForeignKeyAction.CASCADE))
    @KeyColumn(name="LNAME")
    @KeyIndex(name="I_AUTH_LNAME")
    @ElementJoinColumn(name="AUTH_ID")
    @ElementForeignKey(deleteAction=ForeignKeyAction.RESTRICT)
    private Map<String,Author> authors;

    ...
}