ODF document support assumes that objects of a class are persisted to a particular "sheet" of an ODF spreadsheet. Similarly a field of a class is persisted to a particular "column" index of that "sheet". This provides the basis for ODF persistence.

When persisting a Java object to an ODF spreadsheet clearly the user would like some control over what worksheet a class is persisted to, and to what column number a field is persisted. DataNucleus provides extension metadata tags to allow this control. Here's an example, using JDO XML metadata

<jdo>
    <package name="org.datanucleus.samples.models.company">
        <class name="Person" detachable="true" table="People">
            <field name="id">
                <extension vendor-name="datanucleus" key="index" value="0"/>
            </field>
            <field name="firstName">
                <extension vendor-name="datanucleus" key="index" value="1"/>
            </field>
            <field name="lastName">
                <extension vendor-name="datanucleus" key="index" value="2"/>
            </field>
            ...
        </class>
    </package>
</jdo>

Things to note.

• We use the table attribute of class to define the name of the sheet to use for persistence of this class.
• We use the column attribute to define the column name to use for the field (otherwise will be the field name).
• The position of the column defines the position in the worksheet of this column. This is new in JDO3.1. This is optional and the default is to put the fields in alphabetical order.

Here's the same example using JDO Annotations

@PersistenceCapable(table="People")
public class Person
{
    @Column(position=0)
    long id;

    @Column(position=1)
    String firstName;

    @Column(position=2)
    String lastName;

    ...
}

Here's the same example using JPA Annotations (with DataNucleus @Extension/@Extensions annotations)

@Entity
@Table(name="People")
public class Person
{
    @Identity
    @Extension(key="index", value="0")
    long id;

    @Extension(key="index", value="1")
    String firstName;

    @Extension(key="index", value="2")
    String lastName;

    ...
}

Relationships

Obviously a spreadsheet cannot store related objects directly since each object is a row of a particular spreadsheet table. DataNucleus gets around this by storing the String-form of the identity of the related object in the relation cell. See below for an example of the resultant spreadsheet of a class Person that has a 1-1 relation, and a 1-N relation.

In the above example, column 'C' is the 1-N relation, and so elements of the collection are stored as comma-separated object identities. In the same example, column 'D' is the 1-1 relation and the related object is the object identity. When the spreadsheet is read back in again the related object is found.

Table Headers

A typical spreadsheet has many rows of data. It contains no names of columns tying the data back to the input object (field names). DataNucleus allows an extension specified at class level called include-column-headers (should be set to true). When the table is then created it will include an extra row (the first row) with the column names from the metadata (or field names if no column names were defined). For example