Overview | Package | Class | Use | Tree | Deprecated | Index | Help
| Berkeley DB Java Edition version 4.0.103
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## com.sleepycat.persist
Class SecondaryIndex<SK,PK,E>

    java.lang.Object
      com.sleepycat.persist.SecondaryIndex<SK,PK,E>

All Implemented Interfaces:
  EntityIndex<SK,E>

    public class SecondaryIndex<SK,PK,E>

extends Object

The secondary index for an entity class and a secondary key.

`SecondaryIndex` objects are thread-safe. Multiple threads may safely call the methods of a shared `SecondaryIndex` object.

`SecondaryIndex` implements `EntityIndex` to map the secondary key type (SK) to the entity type (E). In other words, entities are accessed by secondary key values.

The `SecondaryKey` annotation may be used to define a secondary key as shown in the following example.

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_ONE)
         String department;

         String name;

         private Employee() {}
     }

Before obtaining a `SecondaryIndex`, the `PrimaryIndex` must be obtained for the entity class. To obtain the `SecondaryIndex` call `EntityStore.getSecondaryIndex`, passing the primary index, the secondary key class and the secondary key name. For example:

     EntityStore store = new EntityStore(...);

     PrimaryIndex<Long, Employee> primaryIndex =
         store.getPrimaryIndex(Long.class, Employee.class);

     SecondaryIndex<String, Long, Employee> secondaryIndex =
         store.getSecondaryIndex(primaryIndex, String.class, "department");

Since `SecondaryIndex` implements the `EntityIndex` interface, it shares the common index methods for retrieving and deleting entities, opening cursors and using transactions. See `EntityIndex` for more information on these topics.

`SecondaryIndex` does not provide methods for inserting and updating entities. That must be done using the `PrimaryIndex`.

Note that a `SecondaryIndex` has three type parameters `<SK, PK, E>` or in the example `<String, Long, Employee>` while a `PrimaryIndex` has only two type parameters `<PK, E>` or `<Long, Employee>`. This is because a `SecondaryIndex` has an extra level of mapping: It maps from secondary key to primary key, and then from primary key to entity. For example, consider this entity:

ID | Department | Name
--- | --- | ---
1 | Engineering | Jane Smith

The `PrimaryIndex` maps from id directly to the entity, or from primary key 1 to the "Jane Smith" entity in the example. The `SecondaryIndex` maps from department to id, or from secondary key "Engineering" to primary key 1 in the example, and then uses the `PrimaryIndex` to map from the primary key to the entity.

Because of this extra type parameter and extra level of mapping, a `SecondaryIndex` can provide more than one mapping, or view, of the entities in the primary index. The main mapping of a `SecondaryIndex` is to map from secondary key (SK) to entity (E), or in the example, from the String department key to the Employee entity. The `SecondaryIndex` itself, by implementing `EntityIndex<SK, E>`, provides this mapping.

The second mapping provided by `SecondaryIndex` is from secondary key (SK) to primary key (PK), or in the example, from the String department key to the Long id key. The `keysIndex` method provides this mapping. When accessing the keys index, the primary key is returned rather than the entity. When only the primary key is needed and not the entire entity, using the keys index is less expensive than using the secondary index because the primary index does not have to be accessed.

The third mapping provided by `SecondaryIndex` is from primary key (PK) to entity (E), for the subset of entities having a given secondary key (SK). This mapping is provided by the `subIndex(SK)` method. A sub-index is convenient when you are interested in working with the subset of entities having a particular secondary key value, for example, all employees in a given department.

All three mappings, along with the mapping provided by the `PrimaryIndex`, are shown using example data in the `EntityIndex` interface documentation. See `EntityIndex` for more information.

Note that when using an index, keys and values are stored and retrieved by value not by reference. In other words, if an entity object is stored and then retrieved, or retrieved twice, each object will be a separate instance. For example, in the code below the assertion will always fail.

     MyKey key = ...;
     MyEntity entity1 = index.get(key);
     MyEntity entity2 = index.get(key);
     assert entity1 == entity2; // always fails!

### One-to-One Relationships

A `ONE_TO_ONE` relationship, although less common than other types of relationships, is the simplest type of relationship. A single entity is related to a single secondary key value. For example:

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=ONE_TO_ONE)
         String ssn;

         String name;

         private Employee() {}
     }

     SecondaryIndex<String, Long, Employee> employeeBySsn =
         store.getSecondaryIndex(primaryIndex, String.class, "ssn");

With a `ONE_TO_ONE` relationship, the secondary key must be unique; in other words, no two entities may have the same secondary key value. If an attempt is made to store an entity having the same secondary key value as another existing entity, a `DatabaseException` will be thrown.

Because the secondary key is unique, it is useful to lookup entities by secondary key using `EntityIndex.get(K)`. For example:

     Employee employee = employeeBySsn.get(mySsn);

### Many-to-One Relationships

A `MANY_TO_ONE` relationship is the most common type of relationship. One or more entities is related to a single secondary key value. For example:

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_ONE)
         String department;

         String name;

         private Employee() {}
     }

     SecondaryIndex<String, Long, Employee> employeeByDepartment =
         store.getSecondaryIndex(primaryIndex, String.class, "department");

With a `MANY_TO_ONE` relationship, the secondary key is not required to be unique; in other words, more than one entity may have the same secondary key value. In this example, more than one employee may belong to the same department.

The most convenient way to access the employees in a given department is by using a sub-index. For example:

     EntityIndex<Long, Entity> subIndex = employeeByDepartment.subIndex(myDept);
     EntityCursor<Employee> cursor = subIndex.entities();
     try {
         for (Employee entity : cursor) {
             // Do something with the entity...
         }
     } finally {
         cursor.close();
     }

### One-to-Many Relationships

In a `ONE_TO_MANY` relationship, a single entity is related to one or more secondary key values. For example:

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=ONE_TO_MANY)
         Set<String> emailAddresses = new HashSet<String>;

         String name;

         private Employee() {}
     }

     SecondaryIndex<String, Long, Employee> employeeByEmail =
         store.getSecondaryIndex(primaryIndex, String.class, "emailAddresses");

With a `ONE_TO_MANY` relationship, the secondary key must be unique; in other words, no two entities may have the same secondary key value. In this example, no two employees may have the same email address. If an attempt is made to store an entity having the same secondary key value as another existing entity, a `DatabaseException` will be thrown.

Because the secondary key is unique, it is useful to lookup entities by secondary key using `EntityIndex.get(K)`. For example:

     Employee employee = employeeByEmail.get(myEmailAddress);

The secondary key field for a `ONE_TO_MANY` relationship must be an array or collection type. To access the email addresses of an employee, simply access the collection field directly. For example:

     Employee employee = primaryIndex.get(1); // Get the entity by primary key
     employee.emailAddresses.add(myNewEmail); // Add an email address
     primaryIndex.putNoReturn(1, employee);   // Update the entity

### Many-to-Many Relationships

In a `MANY_TO_MANY` relationship, one or more entities is related to one or more secondary key values. For example:

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_MANY)
         Set<String> organizations = new HashSet<String>;

         String name;

         private Employee() {}
     }

     SecondaryIndex<String, Long, Employee> employeeByOrganization =
         store.getSecondaryIndex(primaryIndex, String.class, "organizations");

With a `MANY_TO_MANY` relationship, the secondary key is not required to be unique; in other words, more than one entity may have the same secondary key value. In this example, more than one employee may belong to the same organization.

The most convenient way to access the employees in a given organization is by using a sub-index. For example:

     EntityIndex<Long, Entity> subIndex = employeeByOrganization.subIndex(myOrg);
     EntityCursor<Employee> cursor = subIndex.entities();
     try {
         for (Employee entity : cursor) {
             // Do something with the entity...
         }
     } finally {
         cursor.close();
     }

The secondary key field for a `MANY_TO_MANY` relationship must be an array or collection type. To access the organizations of an employee, simply access the collection field directly. For example:

     Employee employee = primaryIndex.get(1); // Get the entity by primary key
     employee.organizations.remove(myOldOrg); // Remove an organization
     primaryIndex.putNoReturn(1, employee);   // Update the entity

### Foreign Key Constraints for Related Entities

In all the examples above the secondary key is treated only as a simple value, such as a `String` department field. In many cases, that is sufficient. But in other cases, you may wish to constrain the secondary keys of one entity class to be valid primary keys of another entity class. For example, a Department entity may also be defined:

     @Entity
     class Department {

         @PrimaryKey
         String name;

         String missionStatement;

         private Department() {}
     }

You may wish to constrain the department field values of the Employee class in the examples above to be valid primary keys of the Department entity class. In other words, you may wish to ensure that the department field of an Employee will always refer to a valid Department entity.

You can implement this constraint yourself by validating the department field before you store an Employee. For example:

     PrimaryIndex<String, Department> departmentIndex =
         store.getPrimaryIndex(String.class, Department.class);

     void storeEmployee(Employee employee) throws DatabaseException {
         if (departmentIndex.contains(employee.department)) {
             primaryIndex.putNoReturn(employee);
         } else {
             throw new IllegalArgumentException("Department does not exist: " +
                                                employee.department);
         }
     }

Or, instead you could define the Employee department field as a foreign key, and this validation will be done for you when you attempt to store the Employee entity. For example:

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Department.class)
         String department;

         String name;

         private Employee() {}
     }

The `relatedEntity=Department.class` above defines the department field as a foreign key that refers to a Department entity. Whenever a Employee entity is stored, its department field value will be checked to ensure that a Department entity exists with that value as its primary key. If no such Department entity exists, then a `DatabaseException` is thrown, causing the transaction to be aborted (assuming that transactions are used).

This begs the question: What happens when a Department entity is deleted while one or more Employee entities have department fields that refer to the deleted department's primary key? If the department were allowed to be deleted, the foreign key constraint for the Employee department field would be violated, because the Employee department field would refer to a department that does not exist.

By default, when this situation arises the system does not allow the department to be deleted. Instead, a `DatabaseException` is thrown, causing the transaction to be aborted. In this case, in order to delete a department, the department field of all Employee entities must first be updated to refer to a different existing department, or set to null. This is the responsibility of the application.

There are two additional ways of handling deletion of a Department entity. These alternatives are configured using the `SecondaryKey.onRelatedEntityDelete()` annotation property. Setting this property to `DeleteAction.NULLIFY` causes the Employee department field to be automatically set to null when the department they refer to is deleted. This may or may not be desirable, depending on application policies. For example:

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Department.class,
                                           onRelatedEntityDelete=NULLIFY)
         String department;

         String name;

         private Employee() {}
     }

The `DeleteAction.CASCADE` value, on the other hand, causes the Employee entities to be automatically deleted when the department they refer to is deleted. This is probably not desirable in this particular example, but is useful for parent-child relationships. For example:

     @Entity
     class Order {

         @PrimaryKey
         long id;

         String description;

         private Order() {}
     }

     @Entity
     class OrderItem {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Order.class,
                                           onRelatedEntityDelete=CASCADE)
         long orderId;

         String description;

         private OrderItem() {}
     }

The OrderItem orderId field refers to its "parent" Order entity. When an Order entity is deleted, it may be useful to automatically delete its "child" OrderItem entities.

For more information, see `SecondaryKey.onRelatedEntityDelete()`.

### One-to-Many versus Many-to-One for Related Entities

When there is a conceptual Many-to-One relationship such as Employee to Department as illustrated in the examples above, the relationship may be implemented either as Many-to-One in the Employee class or as One-to-Many in the Department class.

Here is the Many-to-One approach.

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Department.class)
         String department;

         String name;

         private Employee() {}
     }

     @Entity
     class Department {

         @PrimaryKey
         String name;

         String missionStatement;

         private Department() {}
     }

And here is the One-to-Many approach.

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         String name;

         private Employee() {}
     }

     @Entity
     class Department {

         @PrimaryKey
         String name;

         String missionStatement;

         @SecondaryKey(relate=ONE_TO_MANY, relatedEntity=Employee.class)
         Set<Long> employees = new HashSet<Long>;

         private Department() {}
     }

Which approach is best? The Many-to-One approach better handles large number of entities on the to-Many side of the relationship because it doesn't store a collection of keys as an entity field. With Many-to-One a Btree is used to store the collection of keys and the Btree can easily handle very large numbers of keys. With One-to-Many, each time a related key is added or removed the entity on the One side of the relationship, along with the complete collection of related keys, must be updated. Therefore, if large numbers of keys may be stored per relationship, Many-to-One is recommended.

If the number of entities per relationship is not a concern, then you may wish to choose the approach that is most natural in your application data model. For example, if you think of a Department as containing employees and you wish to modify the Department object each time an employee is added or removed, then you may wish to store a collection of Employee keys in the Department object (One-to-Many).

Note that if you have a One-to-Many relationship and there is no related entity, then you don't have a choice -- you have to use One-to-Many because there is no entity on the to-Many side of the relationship where a Many-to-One key could be defined. An example is the Employee to email addresses relationship discussed above:

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=ONE_TO_MANY)
         Set<String> emailAddresses = new HashSet<String>;

         String name;

         private Employee() {}
     }

For sake of argument imagine that each employee has thousands of email addresses and employees frequently add and remove email addresses. To avoid the potential performance problems associated with updating the Employee entity every time an email address is added or removed, you could create an EmployeeEmailAddress entity and use a Many-to-One relationship as shown below:

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         String name;

         private Employee() {}
     }

     @Entity
     class EmployeeEmailAddress {

         @PrimaryKey
         String emailAddress;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Employee.class)
         long employeeId;

         private EmployeeEmailAddress() {}
     }

### Key Placement with Many-to-Many for Related Entities

As discussed in the section above, one drawback of a to-Many relationship (One-to-Many was discussed above and Many-to-Many is discussed here) is that it requires storing a collection of keys in an entity. Each time a key is added or removed, the containing entity must be updated. This has potential performance problems when there are large numbers of entities on the to-Many side of the relationship, in other words, when there are large numbers of keys in each secondary key field collection.

If you have a Many-to-Many relationship with a reasonably small number of entities on one side of the relationship and a large number of entities on the other side, you can avoid the potential performance problems by defining the secondary key field on the side with a small number of entities.

For example, in an Employee-to-Organization relationship, the number of organizations per employee will normally be reasonably small but the number of employees per organization may be very large. Therefore, to avoid potential performance problems, the secondary key field should be defined in the Employee class as shown below.

     @Entity
     class Employee {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_MANY, relatedEntity=Organization.class)
         Set<String> organizations = new HashSet<String>;

         String name;

         private Employee() {}
     }

     @Entity
     class Organization {

         @PrimaryKey
         String name;

         String description;
     }

If instead a `Set<Long> members` key had been defined in the Organization class, this set could potentially have a large number of elements and performance problems could result.

### Many-to-Many Versus a Relationship Entity

If you have a Many-to-Many relationship with a large number of entities on both sides of the relationship, you can avoid the potential performance problems by using a relationship entity. A relationship entity defines the relationship between two other entities using two Many-to-One relationships.

Imagine a relationship between cars and trucks indicating whenever a particular truck was passed on the road by a particular car. A given car may pass a large number of trucks and a given truck may be passed by a large number of cars. First look at a Many-to-Many relationship between these two entities:

     @Entity
     class Car {

         @PrimaryKey
         String licenseNumber;

         @SecondaryKey(relate=MANY_TO_MANY, relatedEntity=Truck.class)
         Set<String> trucksPassed = new HashSet<String>;

         String color;

         private Car() {}
     }

     @Entity
     class Truck {

         @PrimaryKey
         String licenseNumber;

         int tons;

         private Truck() {}
     }

With the Many-to-Many approach above, the `trucksPassed` set could potentially have a large number of elements and performance problems could result.

To apply the relationship entity approach we define a new entity class named CarPassedTruck representing a single truck passed by a single car. We remove the secondary key from the Car class and use two secondary keys in the CarPassedTruck class instead.

     @Entity
     class Car {

         @PrimaryKey
         String licenseNumber;

         String color;

         private Car() {}
     }

     @Entity
     class Truck {

         @PrimaryKey
         String licenseNumber;

         int tons;

         private Truck() {}
     }

     @Entity
     class CarPassedTruck {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Car.class)
         String carLicense;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Truck.class)
         String truckLicense;

         private CarPassedTruck() {}
     }

The CarPassedTruck entity can be used to access the relationship by car license or by truck license.

You may use the relationship entity approach because of the potential performance problems mentioned above. Or, you may choose to use this approach in order to store other information about the relationship. For example, if for each car that passes a truck you wish to record how much faster the car was going than the truck, then a relationship entity is the logical place to store that property. In the example below the speedDifference property is added to the CarPassedTruck class.

     @Entity
     class CarPassedTruck {

         @PrimaryKey
         long id;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Car.class)
         String carLicense;

         @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Truck.class)
         String truckLicense;

         int speedDifference;

         private CarPassedTruck() {}
     }

Be aware that the relationship entity approach adds overhead compared to Many-to-Many. There is one additional entity and one additional secondary key. These factors should be weighed against its advantages and the relevant application access patterns should be considered.

Author:
  Mark Hayes

Constructor Summary
`SecondaryIndex(SecondaryDatabase database, Database keysDatabase, PrimaryIndex<PK,E> primaryIndex, Class<SK> secondaryKeyClass, EntryBinding<SK> secondaryKeyBinding)` Creates a secondary index without using an `EntityStore`.

Method Summary
`boolean` | `contains(K key)` Checks for existence of a key in this index.
`boolean` | `contains(Transaction txn, K key, LockMode lockMode)` Checks for existence of a key in this index.
`long` | `count()` Returns a non-transactional count of the entities in this index.
`boolean` | `delete(K key)` Deletes all entities with a given index key.
`boolean` | `delete(Transaction txn, K key)` Deletes all entities with a given index key.
`EntityCursor<E>` | `entities()` Opens a cursor for traversing all entities in this index.
`EntityCursor<E>` | `entities(K fromKey, boolean fromInclusive, K toKey, boolean toInclusive)` Opens a cursor for traversing entities in a key range.
`EntityCursor<E>` | `entities(Transaction txn, CursorConfig config)` Opens a cursor for traversing all entities in this index.
`EntityCursor<E>` | `entities(Transaction txn, K fromKey, boolean fromInclusive, K toKey, boolean toInclusive, CursorConfig config)` Opens a cursor for traversing entities in a key range.
`E` | `get(SK key)` Gets an entity via a key of this index.
`E` | `get(Transaction txn, SK key, LockMode lockMode)` Gets an entity via a key of this index.
`SecondaryDatabase` | `getDatabase()` Returns the underlying secondary database for this index.
`EntryBinding<SK>` | `getKeyBinding()` Returns the secondary key binding for the index.
`Class<SK>` | `getKeyClass()` Returns the secondary key class for this index.
`Database` | `getKeysDatabase()` Returns the underlying secondary database that is not associated with the primary database and is used for the `keysIndex`.
`PrimaryIndex<PK,E>` | `getPrimaryIndex()` Returns the primary index associated with this secondary index.
`EntityCursor<K>` | `keys()` Opens a cursor for traversing all keys in this index.
`EntityCursor<K>` | `keys(K fromKey, boolean fromInclusive, K toKey, boolean toInclusive)` Opens a cursor for traversing keys in a key range.
`EntityCursor<K>` | `keys(Transaction txn, CursorConfig config)` Opens a cursor for traversing all keys in this index.
`EntityCursor<K>` | `keys(Transaction txn, K fromKey, boolean fromInclusive, K toKey, boolean toInclusive, CursorConfig config)` Opens a cursor for traversing keys in a key range.
`EntityIndex<SK,PK>` | `keysIndex()` Returns a read-only keys index that maps secondary key to primary key.
`Map<SK,E>` | `map()` Returns a standard Java map based on this entity index.
`SortedMap<SK,E>` | `sortedMap()` Returns a standard Java sorted map based on this entity index.
`EntityIndex<PK,E>` | `subIndex(SK key)` Returns an index that maps primary key to entity for the subset of entities having a given secondary key (duplicates).

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Constructor Detail

### SecondaryIndex

    public SecondaryIndex(SecondaryDatabase database,
                          Database keysDatabase,
                          PrimaryIndex<PK,E> primaryIndex,
                          Class<SK> secondaryKeyClass,
                          EntryBinding<SK> secondaryKeyBinding)
                   throws DatabaseException

  Creates a secondary index without using an `EntityStore`. When using an `EntityStore`, call `getSecondaryIndex` instead.

  This constructor is not normally needed and is provided for applications that wish to use custom bindings along with the Direct Persistence Layer. Normally, `getSecondaryIndex` is used instead.

  Parameters:
    `database` - the secondary database used for all access other than via a `keysIndex`.
    `keysDatabase` - another handle on the secondary database, opened without association to the primary, and used only for access via a `keysIndex`. If this argument is null and the `keysIndex` method is called, then the keys database will be opened automatically; however, the user is then responsible for closing the keys database. To get the keys database in order to close it, call `getKeysDatabase()`.
    `primaryIndex` - the primary index associated with this secondary index.
    `secondaryKeyClass` - the class of the secondary key.
    `secondaryKeyBinding` - the binding to be used for secondary keys.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

Method Detail

### getDatabase

    public SecondaryDatabase getDatabase()

  Returns the underlying secondary database for this index.

  Returns:
    the secondary database.

### getKeysDatabase

    public Database getKeysDatabase()

  Returns the underlying secondary database that is not associated with the primary database and is used for the `keysIndex`.

  Returns:
    the keys database.

### getPrimaryIndex

    public PrimaryIndex<PK,E> getPrimaryIndex()

  Returns the primary index associated with this secondary index.

  Returns:
    the primary index.

### getKeyClass

    public Class<SK> getKeyClass()

  Returns the secondary key class for this index.

  Returns:
    the class.

### getKeyBinding

    public EntryBinding<SK> getKeyBinding()

  Returns the secondary key binding for the index.

  Returns:
    the key binding.

### keysIndex

    public EntityIndex<SK,PK> keysIndex()
                                 throws DatabaseException

  Returns a read-only keys index that maps secondary key to primary key. When accessing the keys index, the primary key is returned rather than the entity. When only the primary key is needed and not the entire entity, using the keys index is less expensive than using the secondary index because the primary index does not have to be accessed.

  Note the following in the unusual case that you are not using an `EntityStore`: This method will open the keys database, a second database handle for the secondary database, if it is not already open. In this case, if you are not using an `EntityStore`, then you are responsible for closing the database returned by `getKeysDatabase()` before closing the environment. If you are using an `EntityStore`, the keys database will be closed automatically by `EntityStore.close()`.

  Returns:
    the keys index.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### subIndex

    public EntityIndex<PK,E> subIndex(SK key)
                               throws DatabaseException

  Returns an index that maps primary key to entity for the subset of entities having a given secondary key (duplicates). A sub-index is convenient when you are interested in working with the subset of entities having a particular secondary key value.

  When using a `MANY_TO_ONE` or `MANY_TO_MANY` secondary key, the sub-index represents the left (MANY) side of a relationship.

  Parameters:
    `key` - the secondary key that identifies the entities in the sub-index.
  Returns:
    the sub-index.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### get

    public E get(SK key)
          throws DatabaseException

  Description copied from interface: `EntityIndex`
  Gets an entity via a key of this index.

  The operation will not be transaction protected, and `LockMode.DEFAULT` is used implicitly.

  Parameters:
    `key` - the key to search for.
  Returns:
    the value mapped to the given key, or null if the key is not present in the index.
  Throws:
    `OperationFailureException` - if one of the Read Operation Failures occurs.
    `EnvironmentFailureException` - if an unexpected, internal or environment-wide failure occurs.
    `DatabaseException` - the base class for all BDB exceptions.

### get

    public E get(Transaction txn,
                 SK key,
                 LockMode lockMode)
          throws DatabaseException

  Description copied from interface: `EntityIndex`
  Gets an entity via a key of this index.

  Parameters:
    `txn` - the transaction used to protect this operation, or null if the operation should not be transaction protected.
    `key` - the key to search for.
    `lockMode` - the lock mode to use for this operation, or null to use `LockMode.DEFAULT`.
  Returns:
    the value mapped to the given key, or null if the key is not present in the index.
  Throws:
    `OperationFailureException` - if one of the Read Operation Failures occurs.
    `EnvironmentFailureException` - if an unexpected, internal or environment-wide failure occurs.
    `DatabaseException` - the base class for all BDB exceptions.

### map

    public Map<SK,E> map()

  Description copied from interface: `EntityIndex`
  Returns a standard Java map based on this entity index. The `StoredMap` returned is defined by the Collections API. Stored collections conform to the standard Java collections framework interface.

  Returns:
    the map.

### sortedMap

    public SortedMap<SK,E> sortedMap()

  Description copied from interface: `EntityIndex`
  Returns a standard Java sorted map based on this entity index. The `StoredSortedMap` returned is defined by the Collections API. Stored collections conform to the standard Java collections framework interface.

  Returns:
    the map.

### contains

    public boolean contains(K key)
                     throws DatabaseException

  Description copied from interface: `EntityIndex`
  Checks for existence of a key in this index.

  The operation will not be transaction protected, and `LockMode.DEFAULT` is used implicitly.

  `READ_UNCOMMITTED` can be used with this method to reduce I/O, since the record data item will not be read. This is the same benefit as described in Key Cursor Optimization with READ_UNCOMMITTED

  Specified by:
    `contains` in interface `EntityIndex<K,E>`
  Parameters:
    `key` - the key to search for.
  Returns:
    whether the key exists in the index.
  Throws:
    `OperationFailureException` - if one of the Read Operation Failures occurs.
    `EnvironmentFailureException` - if an unexpected, internal or environment-wide failure occurs.
    `DatabaseException` - the base class for all BDB exceptions.

### contains

    public boolean contains(Transaction txn,
                            K key,
                            LockMode lockMode)
                     throws DatabaseException

  Description copied from interface: `EntityIndex`
  Checks for existence of a key in this index.

  `READ_UNCOMMITTED` can be used with this method to reduce I/O, since the record data item will not be read. This is the same benefit as described in Key Cursor Optimization with READ_UNCOMMITTED

  Specified by:
    `contains` in interface `EntityIndex<K,E>`
  Parameters:
    `txn` - the transaction used to protect this operation, or null if the operation should not be transaction protected.
    `key` - the key to search for.
    `lockMode` - the lock mode to use for this operation, or null to use `LockMode.DEFAULT`.
  Returns:
    whether the key exists in the index.
  Throws:
    `OperationFailureException` - if one of the Read Operation Failures occurs.
    `EnvironmentFailureException` - if an unexpected, internal or environment-wide failure occurs.
    `DatabaseException` - the base class for all BDB exceptions.

### count

    public long count()
               throws DatabaseException

  Description copied from interface: `EntityIndex`
  Returns a non-transactional count of the entities in this index.

  This operation is faster than obtaining a count by scanning the index manually, and will not perturb the current contents of the cache. However, the count is not guaranteed to be accurate if there are concurrent updates.

  Specified by:
    `count` in interface `EntityIndex<K,E>`
  Returns:
    the number of entities in this index.
  Throws:
    `OperationFailureException` - if one of the Read Operation Failures occurs.
    `EnvironmentFailureException` - if an unexpected, internal or environment-wide failure occurs.
    `DatabaseException` - the base class for all BDB exceptions.

### delete

    public boolean delete(K key)
                   throws DatabaseException

  Description copied from interface: `EntityIndex`
  Deletes all entities with a given index key.

  Auto-commit is used implicitly if the store is transactional.

  Specified by:
    `delete` in interface `EntityIndex<K,E>`
  Parameters:
    `key` - the key to search for.
  Returns:
    whether any entities were deleted.
  Throws:
    `OperationFailureException` - if one of the Write Operation Failures occurs.
    `EnvironmentFailureException` - if an unexpected, internal or environment-wide failure occurs.
    `DatabaseException` - the base class for all BDB exceptions.

### delete

    public boolean delete(Transaction txn,
                          K key)
                   throws DatabaseException

  Description copied from interface: `EntityIndex`
  Deletes all entities with a given index key.

  Specified by:
    `delete` in interface `EntityIndex<K,E>`
  Parameters:
    `txn` - the transaction used to protect this operation, null to use auto-commit, or null if the store is non-transactional.
    `key` - the key to search for.
  Returns:
    whether any entities were deleted.
  Throws:
    `OperationFailureException` - if one of the Write Operation Failures occurs.
    `EnvironmentFailureException` - if an unexpected, internal or environment-wide failure occurs.
    `DatabaseException` - the base class for all BDB exceptions.

### keys

    public EntityCursor<K> keys()
                         throws DatabaseException

  Description copied from interface: `EntityIndex`
  Opens a cursor for traversing all keys in this index.

  The operations performed with the cursor will not be transaction protected, and `CursorConfig.DEFAULT` is used implicitly. If the store is transactional, the cursor may not be used to update or delete entities.

  Note that `READ_UNCOMMITTED` can be used with a key cursor to reduce I/O, potentially providing significant performance benefits. See Key Cursor Optimization with READ_UNCOMMITTED

  Specified by:
    `keys` in interface `EntityIndex<K,E>`
  Returns:
    the cursor.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### keys

    public EntityCursor<K> keys(Transaction txn,
                                CursorConfig config)
                         throws DatabaseException

  Description copied from interface: `EntityIndex`
  Opens a cursor for traversing all keys in this index.

  Note that `READ_UNCOMMITTED` can be used with a key cursor to reduce I/O, potentially providing significant performance benefits. See Key Cursor Optimization with READ_UNCOMMITTED

  Specified by:
    `keys` in interface `EntityIndex<K,E>`
  Parameters:
    `txn` - the transaction used to protect all operations performed with the cursor, or null if the operations should not be transaction protected. If the store is non-transactional, null must be specified. For a transactional store the transaction is optional for read-only access and required for read-write access.
    `config` - the cursor configuration that determines the default lock mode used for all cursor operations, or null to implicitly use `CursorConfig.DEFAULT`.
  Returns:
    the cursor.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### entities

    public EntityCursor<E> entities()
                             throws DatabaseException

  Description copied from interface: `EntityIndex`
  Opens a cursor for traversing all entities in this index.

  The operations performed with the cursor will not be transaction protected, and `CursorConfig.DEFAULT` is used implicitly. If the store is transactional, the cursor may not be used to update or delete entities.

  Specified by:
    `entities` in interface `EntityIndex<K,E>`
  Returns:
    the cursor.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### entities

    public EntityCursor<E> entities(Transaction txn,
                                    CursorConfig config)
                             throws DatabaseException

  Description copied from interface: `EntityIndex`
  Opens a cursor for traversing all entities in this index.

  Specified by:
    `entities` in interface `EntityIndex<K,E>`
  Parameters:
    `txn` - the transaction used to protect all operations performed with the cursor, or null if the operations should not be transaction protected. If the store is non-transactional, null must be specified. For a transactional store the transaction is optional for read-only access and required for read-write access.
    `config` - the cursor configuration that determines the default lock mode used for all cursor operations, or null to implicitly use `CursorConfig.DEFAULT`.
  Returns:
    the cursor.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### keys

    public EntityCursor<K> keys(K fromKey,
                                boolean fromInclusive,
                                K toKey,
                                boolean toInclusive)
                         throws DatabaseException

  Description copied from interface: `EntityIndex`
  Opens a cursor for traversing keys in a key range.

  The operations performed with the cursor will not be transaction protected, and `CursorConfig.DEFAULT` is used implicitly. If the store is transactional, the cursor may not be used to update or delete entities.

  Note that `READ_UNCOMMITTED` can be used with a key cursor to reduce I/O, potentially providing significant performance benefits. See Key Cursor Optimization with READ_UNCOMMITTED

  Specified by:
    `keys` in interface `EntityIndex<K,E>`
  Parameters:
    `fromKey` - is the lower bound of the key range, or null if the range has no lower bound.
    `fromInclusive` - is true if keys greater than or equal to fromKey should be included in the key range, or false if only keys greater than fromKey should be included.
    `toKey` - is the upper bound of the key range, or null if the range has no upper bound.
    `toInclusive` - is true if keys less than or equal to toKey should be included in the key range, or false if only keys less than toKey should be included.
  Returns:
    the cursor.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### keys

    public EntityCursor<K> keys(Transaction txn,
                                K fromKey,
                                boolean fromInclusive,
                                K toKey,
                                boolean toInclusive,
                                CursorConfig config)
                         throws DatabaseException

  Description copied from interface: `EntityIndex`
  Opens a cursor for traversing keys in a key range.

  #### Key Cursor Optimization with READ_UNCOMMITTED

  Using a key cursor potentially has a large performance benefit when the `READ_UNCOMMITTED` isolation mode is used. In this case, if the record data is not in the JE cache, it will not be read from disk. The performance benefit is potentially large because random access disk reads may be reduced. Examples are:

  - Scanning all records in key order, when the entity is not needed and `READ_UNCOMMITTED` isolation is acceptable.
  - Skipping over records quickly to perform approximate pagination with `READ_UNCOMMITTED` isolation.

  For other isolation modes (`READ_COMMITTED`, `REPEATABLE_READ` and `SERIALIZABLE`), the performance benefit of a key cursor is not as significant. In this case, the data item must be read into the JE cache if it is not already present, in order to lock the record. The only performance benefit is that the data will not be copied from the JE cache to the application's entry parameter, and will not be unmarshalled into an entity object.

  For information on specifying isolation modes, see `LockMode`, `CursorConfig` and `TransactionConfig`.

  Specified by:
    `keys` in interface `EntityIndex<K,E>`
  Parameters:
    `txn` - the transaction used to protect all operations performed with the cursor, or null if the operations should not be transaction protected. If the store is non-transactional, null must be specified. For a transactional store the transaction is optional for read-only access and required for read-write access.
    `fromKey` - is the lower bound of the key range, or null if the range has no lower bound.
    `fromInclusive` - is true if keys greater than or equal to fromKey should be included in the key range, or false if only keys greater than fromKey should be included.
    `toKey` - is the upper bound of the key range, or null if the range has no upper bound.
    `toInclusive` - is true if keys less than or equal to toKey should be included in the key range, or false if only keys less than toKey should be included.
    `config` - the cursor configuration that determines the default lock mode used for all cursor operations, or null to implicitly use `CursorConfig.DEFAULT`.
  Returns:
    the cursor.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### entities

    public EntityCursor<E> entities(K fromKey,
                                    boolean fromInclusive,
                                    K toKey,
                                    boolean toInclusive)
                             throws DatabaseException

  Description copied from interface: `EntityIndex`
  Opens a cursor for traversing entities in a key range.

  The operations performed with the cursor will not be transaction protected, and `CursorConfig.DEFAULT` is used implicitly. If the store is transactional, the cursor may not be used to update or delete entities.

  Specified by:
    `entities` in interface `EntityIndex<K,E>`
  Parameters:
    `fromKey` - is the lower bound of the key range, or null if the range has no lower bound.
    `fromInclusive` - is true if keys greater than or equal to fromKey should be included in the key range, or false if only keys greater than fromKey should be included.
    `toKey` - is the upper bound of the key range, or null if the range has no upper bound.
    `toInclusive` - is true if keys less than or equal to toKey should be included in the key range, or false if only keys less than toKey should be included.
  Returns:
    the cursor.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

### entities

    public EntityCursor<E> entities(Transaction txn,
                                    K fromKey,
                                    boolean fromInclusive,
                                    K toKey,
                                    boolean toInclusive,
                                    CursorConfig config)
                             throws DatabaseException

  Description copied from interface: `EntityIndex`
  Opens a cursor for traversing entities in a key range.

  Specified by:
    `entities` in interface `EntityIndex<K,E>`
  Parameters:
    `txn` - the transaction used to protect all operations performed with the cursor, or null if the operations should not be transaction protected. If the store is non-transactional, null must be specified. For a transactional store the transaction is optional for read-only access and required for read-write access.
    `fromKey` - is the lower bound of the key range, or null if the range has no lower bound.
    `fromInclusive` - is true if keys greater than or equal to fromKey should be included in the key range, or false if only keys greater than fromKey should be included.
    `toKey` - is the upper bound of the key range, or null if the range has no upper bound.
    `toInclusive` - is true if keys less than or equal to toKey should be included in the key range, or false if only keys less than toKey should be included.
    `config` - the cursor configuration that determines the default lock mode used for all cursor operations, or null to implicitly use `CursorConfig.DEFAULT`.
  Returns:
    the cursor.
  Throws:
    `DatabaseException` - the base class for all BDB exceptions.

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
| Berkeley DB Java Edition version 4.0.103
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright (c) 2004-2010 Oracle. All rights reserved.