4.3. Field-level Object-Relational Mapping Extensions

4.3.1. dependent
4.3.2. element-dependent
4.3.3. value-dependent
4.3.4. key-dependent
4.3.5. inverse
4.3.6. blob
4.3.7. column-length
4.3.8. column-index
4.3.9. ordered
4.3.10. table
4.3.11. data-column
4.3.12. key-column
4.3.13. ref-column
4.3.14. order-column
4.3.15. read-only
4.3.16. <tablename>-pk-column
4.3.17. fetch-group
4.3.18. custom-mapping
4.3.19. externalizer
4.3.20. factory

The following keys are recognized for extension elements that are direct children of field elements in the metadata document.

4.3.1. dependent

Setting a value of true for this extension indicates that the persistent object stored in this field should be deleted when the parent object is deleted. The deletion of dependent field values occurs during the commit process.

4.3.2. element-dependent

This extension is equivalent to the dependent extension above, but applies to the element values of collection fields. Use this extension for one-to-many or many-to-many relations where the related objects should be deleted along with the owning object.

4.3.3. value-dependent

This extension is equivalent to the dependent extension above, but applies to first class map values.

4.3.4. key-dependent

This extension is equivalent to the dependent extension above, but applies to first class map keys (note: first class map keys are not yet supported.

4.3.5. inverse

Specifies the field name of the other side of a two-sided relationship between objects. It is safe to leave out this extension, but the relational schema can be more efficient when the inverse is known. In object-relational mapping terms, inverses are used to detect 2-sided one-to-ones, one-to-many and 2-sided many-to-many mappings.

4.3.6. blob

Takes a value of true or false. This extension can be used to explicitly mark fields that should be stored as serialized BLOB values. For example, Kodo JDO would normally store a field of type byte[] using a secondary table with a row for each byte value in the array; this type of storage allows for queries on the array. If the byte[] is large or contains information that should not be query-able, it may be more efficient to store it as a BLOB column of the main table. Fields that Kodo JDO cannot normally persist, such as user-defined interface fields or fields of type java.lang.Object are defaulted to use BLOB mappings. In these cases this extension is not necessary, though it is still allowed.

4.3.7. column-length

String fields can specify the maximum length of the String that will be stored in the database column. The default maximum is 255 characters. Use a value of -1 to indicate that there should be no length limit on the String. In this case, the column will be created as a CLOB, or the correct database equivalent.

4.3.8. column-index

This extension takes a value of true or false to specify whether the column holding the data for the field should be indexed.

4.3.9. ordered

This extension accepts a value of true or false. By default, databases do not guarantee the order in which results are read. Thus, collection and array field elements may be retrieved from the database in a different order from the one in which they were stored. A value of true for this key, however, will ensure that the order of the elements in this field is retained during database reads. This flag is useful only for collection and array fields that represent a one-sided relationship, such as a collection of simple values or a 1-sided many-to-many relation. It cannot be used for one-to-many relations or shared many-to-many relations. See the order-column extension for more information.

4.3.10. table

Some mappings do not store their data in the class' primary table. This extension specifies the table where the data for this field is stored. This attribute is also used in multi-table inheritance mappings.

For collection, array, and map fields, this is the secondary or cross-reference table used to hold the field value. Normally, Kodo JDO auto-generates secondary tables based on the class and field name. Note that this extension should not be used for one-to-many collections, since there is no secondary table for such collections.

4.3.11. data-column

This extension specifies the column in which the data for this field is stored. For simple fields, this column must belong to the primary table of the class (i.e., the table in which the primary key value is stored). For collection and map fields, this column can belong to a secondary table, as long as an additional ref column is provided to link the secondary table to the primary (see below). If this field represents a relation to another persistent object, the named column should hold the primary key value of the related instance. Note that this extension is ignored if the class to which this field refers uses application identity. The next section covers application identity extensions.

4.3.12. key-column

This extension is applicable only to map fields. It specifies the column of the secondary table that holds the key values.

4.3.13. ref-column

This extension is only for a collection or map field whose data column exists in a secondary table. The ref-column must be in the same table as the data column, and must contain the primary key value of the owning instance. This allows a SQL join to be performed linking this ref column with the primary key column of the primary table. Note that this extension is ignored if the class to which this field refers uses application identity.

4.3.14. order-column

This extension is applicable only to collection fields that also have the ordered extension. It specifies the column of the secondary table used to hold ordering information. This column must be of a numeric type. If the ordered extension is given but this extension is omitted, Kodo JDO will create its own order column, usually named JDOORDERX.

4.3.15. read-only

This extension is used for inverse one-to-one relations and collection fields that represent a shared many-to-many mapping.

In inverse one-to-one relations, this meta data flag marks which class does not own the field in its table, and thus has a read-only view of the relational data. If neither side of such a relation is marked read-only, Kodo will automatically choose one side as such.

In many-to-many collection field mappings, one class can declare its field to be read-only in order to avoid duplicate inserts into the shared table. The value of this extension should be either true or false. Note that Kodo JDO typically makes one side of the relation read-only automatically; this extension is never strictly needed.

4.3.16. <tablename>-pk-column

This extension specifies the primary key column to use for the table tablename. It is a valid extension to primary-key fields (those fields with the JDO primary-key field-level attribute set to true).

4.3.17. fetch-group

fetch-group: This optional extension stores the name of the custom fetch group in which this field should be included. Zero or one fetch-group extensions may be specified. The field-level default-fetch-group attribute must be set to false if this extension is present. See the fetch groups documentation for more information.

4.3.18. custom-mapping

This optional extension stores the name of the FieldMapping subclass to use for this field.

4.3.19. externalizer

The method to invoke in order to externalize the field to a String, for storing as a String. The method can be a non-static method to invoke on the field value, or a static method that will take the field value as a parameter. See the Storing Second Class Objects via Stringification documentation.

4.3.20. factory

The method to invoke in order to instantiate the field to a String, when storage is performed via stringification. The method should be a static method that takes a single String argument. When unset, the String constructor of the field type will be invoked. See the Storing Second Class Objects via Stringification documentation.