Berkeley DB version 4.7.25

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

    @Documented
    @Retention(value=RUNTIME)
    @Target(value=TYPE)
    public @interface Entity

Indicates a persistent entity class. For each entity class, a `PrimaryIndex` can be used to store and access instances of that class. Optionally, one or more `SecondaryIndex` objects may be used to access entity instances by secondary key.

Entity Subclasses and Superclasses

An entity class may have any number of subclasses and superclasses; however, none of these may themselves be entity classes (annotated with `Entity`).

Entity superclasses are used to share common definitions and instance data. For example, fields in an entity superclass may be defined as primary or secondary keys.

Entity subclasses are used to provide polymorphism within a single `PrimaryIndex`. Instances of the entity class and its subclasses are stored in the same `PrimaryIndex`. Fields in an entity subclass may be defined as secondary keys.

For example, the following `BaseClass` defines the primary key for any number of entity classes, using a single sequence to assign primary key values. The entity class `Pet` extends the base class, implicitly defining a primary index that will contain instances of it and its subclasses, including `Cat` which is defined below. The primary key (`id`) and secondary key (`name`) can be used to retrieve any `Pet` instance.

      @Persistent
      class BaseClass {
          @PrimaryKey(sequence="ID")
          long id;
      }

      @Entity
      class Pet extends BaseClass {
          @SecondaryKey(relate=ONE_TO_ONE)
          String name;
          float height;
          float weight;
      }

The entity subclass `Cat` defines a secondary key (`finickyness`) that only applies to `Cat` instances. Querying by this key will never retrieve a `Dog` instance, if such a subclass existed, because a `Dog` instance will never contain a `finickyness` key.

      @Persistent
      class Cat extends Pet {
          @SecondaryKey(relate=MANY_TO_ONE)
          int finickyness;
      }

Persistent Fields and Types

All non-transient instance fields of an entity class, as well as its superclasses and subclasses, are persistent. `static` and `transient` fields are not persistent. The persistent fields of a class may be `private`, package-private (default access), `protected` or `public`.

It is worthwhile to note the reasons that object persistence is defined in terms of fields rather than properties (getters and setters). This allows business methods (getters and setters) to be defined independently of the persistent state of an object; for example, a setter method may perform validation that could not be performed if it were called during object deserialization. Similarly, this allows public methods to evolve somewhat independently of the (typically non-public) persistent fields.

Simple Types

Persistent types are divided into simple types, enum types, complex types, and array types. Simple types and enum types are single valued, while array types may contain multiple elements and complex types may contain one or more named fields.

Simple types include:

- Java primitive types: `boolean, char, byte, short, int, long, float, double`
- The wrapper classes for Java primitive types
- `BigInteger`
- `String`
- `Date`

When null values are required (for optional key fields, for example), primitive wrapper classes must be used instead of primitive types.

Simple types, enum types and array types do not require annotations to make them persistent.

Complex and Proxy Types

Complex persistent classes must be annotated with `Entity` or `Persistent`, or must be proxied by a persistent proxy class (described below). This includes entity classes, subclasses and superclasses, and all other complex classes referenced via fields of these classes.

All complex persistent classes must have a default constructor. The default constructor may be `private`, package-private (default access), `protected`, or `public`. Other constructors are allowed but are not used by the persistence mechanism.

It is sometimes desirable to store instances of a type that is externally defined and cannot be annotated or does not have a default constructor; for example, a class defined in the Java standard libraries or a 3rd party library. In this case, a `PersistentProxy` class may be used to represent the stored values for the externally defined type. The proxy class itself must be annotated with `Persistent` like other persistent classes, and the `Persistent.proxyFor()` property must be specified.

For convenience, built-in proxy classes are included for several common classes (listed below) in the Java library. If you wish, you may define your own `PersistentProxy` to override these built-in proxies.

- `HashSet`
- `TreeSet`
- `HashMap`
- `TreeMap`
- `ArrayList`
- `LinkedList`

Complex persistent types should in general be application-defined classes. This gives the application control over the persistent state and its evolution over time.

Other Type Restrictions

Entity classes and subclasses may not be used in field declarations for persistent types. Fields of entity classes and subclasses must be simple types or non-entity persistent types (annotated with `Persistent` not with `Entity`).

Entity classes, subclasses and superclasses may be `abstract` and may implement arbitrary interfaces. Interfaces do not need to be annotated with `Persistent` in order to be used in a persistent class, since interfaces do not contain instance fields.

Persistent instances of static nested classes are allowed, but the nested class must be annotated with `Persistent` or `Entity`. Inner classes (non-static nested classes, including anonymous classes) are not currently allowed as persistent types.

Arrays of simple and persistent complex types are allowed as fields of persistent types. Arrays may be multidimensional. However, an array may not be stored as a top level instance in a primary index. Only instances of entity classes and subclasses may be top level instances in a primary index.

Embedded Objects

As stated above, the embedded (or member) non-transient non-static fields of an entity class are themselves persistent and are stored along with their parent entity object. This allows embedded objects to be stored in an entity to an arbitrary depth.

There is no arbitrary limit to the nesting depth of embedded objects within an entity; however, there is a practical limit. When an entity is marshalled, each level of nesting is implemented internally via recursive method calls. If the nesting depth is large enough, a `StackOverflowError` can occur. In practice, this has been observed with a nesting depth of 12,000, using the default Java stack size.

This restriction on the nesting depth of embedded objects does not apply to cyclic references, since these are handled specially as described below.

Object Graphs

When an entity instance is stored, the graph of objects referenced via its fields is stored and retrieved as a graph. In other words, if a single instance is referenced by two or more fields when the entity is stored, the same will be true when the entity is retrieved.

When a reference to a particular object is stored as a member field inside that object or one of its embedded objects, this is called a cyclic reference. Because multiple references to a single object are stored as such, cycles are also represented correctly and do not cause infinite recursion or infinite processing loops. If an entity containing a cyclic reference is stored, the cyclic reference will be present when the entity is retrieved.

Note that the stored object graph is restricted in scope to a single entity instance. This is because each entity instance is stored separately. If two entities have a reference to the same object when stored, they will refer to two separate instances when the entities are retrieved.

See Also:
  `Persistent`, `PrimaryKey`, `SecondaryKey`, `KeyField`

Optional Element Summary
`int` `version` Identifies a new version of a class when an incompatible class change has been made.

### version

    public abstract int version

  Identifies a new version of a class when an incompatible class change has been made. Prior versions of a class are referred to by version number to perform class evolution and conversion using `Mutations`.

  The first version of a class is version zero, if `version()` is not specified. When an incompatible class change is made, a version number must be assigned using `version()` that is higher than the previous version number for the class. If this is not done, an `IncompatibleClassException` will be thrown when the store is opened.

  Default:
    0

Berkeley DB version 4.7.25

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