Berkeley DB Java Edition version 3.2.76

## com.sleepycat.persist.model
Annotation Type KeyField

    @Documented
    @Retention(value=RUNTIME)
    @Target(value=FIELD)
    public @interface KeyField

Indicates the sorting position of a key field in a composite key class when the `Comparable` interface is not implemented. The `KeyField` integer value specifies the sort order of this field within the set of fields in the composite key.

If the field type of a `PrimaryKey` or `SecondaryKey` is a composite key class containing more than one key field, then a `KeyField` annotation must be present on each non-transient instance field of the composite key class. The `KeyField` value must be a number between one and the number of non-transient instance fields declared in the composite key class.

Note that a composite key class is a flat container for one or more simple type fields. All non-transient instance fields in the composite key class are key fields, and the composite key class may not have superclasses containing non-transient instance fields.

For example:

      @Entity
      class Animal {
          @PrimaryKey
          Classification classification;
          ...
      }

      @Persistent
      class Classification {
          @KeyField(1) String kingdom;
          @KeyField(2) String phylum;
          @KeyField(3) String clazz;
          @KeyField(4) String order;
          @KeyField(5) String family;
          @KeyField(6) String genus;
          @KeyField(7) String species;
          @KeyField(8) String subspecies;
          ...
      }

This causes entities to be sorted first by `kingdom`, then by `phylum` within `kingdom`, and so on.

The fields in a composite key class may not be null.

Custom Sort Order

To override the default sort order, a composite key class may implement the `Comparable` interface. This allows overriding the sort order and is therefore useful even when there is only one key field in the composite key class. For example, the following class sorts Strings using a Canadian collator:

      import java.text.Collator;
      import java.util.Locale;

      @Entity
      class Animal {
          ...
          @SecondaryKey(relate=ONE_TO_ONE)
          CollatedString canadianName;
          ...
      }

      @Persistent
      class CollatedString implements Comparable<CollatedString> {

          static Collator collator = Collator.getInstance(Locale.CANADA);

          @KeyField(1)
          String value;

          CollatedString(String value) { this.value = value; }

          private CollatedString() {}

          public int compareTo(CollatedString o) {
              return collator.compare(value, o.value);
          }
      }

Several important rules should be considered when implementing a custom comparison method. Failure to follow these rules may result in the primary or secondary index becoming unusable; in other words, the store will not be able to function.

1. The comparison method must always return the same result, given the same inputs. The behavior of the comparison method must not change over time.
2. A corollary to the first rule is that the behavior of the comparison method must not be dependent on state which may change over time. For example, if the above collation method used the default Java locale, and the default locale is changed, then the sort order will change.
3. The comparison method must not assume that it is called after the store has been opened. With Berkeley DB Java Edition, the comparison method is called during database recovery, which occurs in the `Environment` constructor.
4. The comparison method must not assume that it will only be called with keys that are currently present in the database. The comparison method will occasionally be called with deleted keys or with keys for records that were not part of a committed transaction.

Author:
  Mark Hayes

Required Element Summary
`int` `value`

Element Detail

### value

    public abstract int value

Berkeley DB Java Edition version 3.2.76

Copyright 1996,2008 Oracle. All rights reserved.