Berkeley DB XML
version 2.5.16

Annotation Type KeyField

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 its superclass must be Object.

For example:

  class Animal {
      Classification classification;

  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;

  class Animal {
      CollatedString canadianName;

  class CollatedString implements Comparable<CollatedString> {

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

      String value;

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

      private CollatedString() {}

      public int compareTo(CollatedString o) {
          return, 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.

Required Element Summary
 int value

Element Detail


public abstract int value

Berkeley DB XML
version 2.5.16

Copyright (c) 1996,2009 Oracle. All rights reserved.