Table of Contents
In the prior examples, the keys and values of each store were
represented using separate classes. For example, a PartKey
and a PartData class were used. Many times it is desirable
to have a single class representing both the key and the value, for
example, a Part class.
Such a combined key and value class is called an entity class and is used along with an entity binding. Entity bindings combine a key and a value into an entity when reading a record from a collection, and split an entity into a key and a value when writing a record to a collection. Entity bindings are used in place of value bindings, and entity objects are used with collections in place of value objects.
Some reasons for using entities are:
When the key is a property of an entity object representing the record as a whole, the object's identity and concept are often clearer than with key and value objects that are disjoint.
A single entity object per record is often more convenient to use than two objects.
Of course, instead of using an entity binding, you could simply
create the entity yourself after reading the key and value from a
collection, and split the entity into a key and value yourself
before writing it to a collection. But this would detract from the
convenience of the using the Java collections API. It is convenient
to obtain a Part object directly from
Map.get
and to add a Part object using
Set.add.
Collections having entity bindings can be used naturally without
combining and splitting objects each time a collection method is
called; however, an entity binding class must be defined by the
application.
In addition to showing how to use entity bindings, this example
illustrates a key feature of all bindings: Bindings are independent
of database storage parameters and formats. Compare this example to
the prior Index example and you'll see that the Sample and
SampleViews classes have been changed to use entity
bindings, but the SampleDatabase class was not changed at
all. In fact, the Entity program and the Index program can be used
interchangeably to access the same physical database files. This
demonstrates that bindings are only a "view" onto the physical
stored data.
Warning: When using multiple bindings for the same
database, it is the application's responsibility to ensure that the
same format is used for all bindings. For example, a serial binding
and a tuple binding cannot be used to access the same records.
The complete source of the final version of the example program is included in the Berkeley DB distribution.
As described in the prior section, entity classes are
combined key/value classes that are managed by entity bindings. In
this example the Part, Supplier and Shipment
classes are entity classes. These classes contain fields that are a
union of the fields of the key and value classes that were defined
earlier for each store.
In general, entity classes may be defined in any way desired by the application. The entity binding, which is also defined by the application, is responsible for mapping between key/value objects and entity objects.
The Part, Supplier and Shipment
entity classes are
defined below.
An important difference between the entity classes defined here and the key and value classes defined earlier is that the entity classes are not serializable (do not implement the Serializable interface). This is because the entity classes are not directly stored. The entity binding decomposes an entity object into key and value objects, and only the key and value objects are serialized for storage.
One advantage of using entities can already be seen in the
toString() method of the classes below. These return debugging
output for the combined key and value, and will be used later to
create a listing of the database that is more readable than in the
prior examples.
public class Part
{
private String number;
private String name;
private String color;
private Weight weight;
private String city;
public Part(String number, String name, String color, Weight weight,
String city)
{
this.number = number;
this.name = name;
this.color = color;
this.weight = weight;
this.city = city;
}
public final String getNumber()
{
return number;
}
public final String getName()
{
return name;
}
public final String getColor()
{
return color;
}
public final Weight getWeight()
{
return weight;
}
public final String getCity()
{
return city;
}
public String toString()
{
return "Part: number=" + number +
" name=" + name +
" color=" + color +
" weight=" + weight +
" city=" + city + '.';
}
} public class Supplier
{
private String number;
private String name;
private int status;
private String city;
public Supplier(String number, String name, int status, String city)
{
this.number = number;
this.name = name;
this.status = status;
this.city = city;
}
public final String getNumber()
{
return number;
}
public final String getName()
{
return name;
}
public final int getStatus()
{
return status;
}
public final String getCity()
{
return city;
}
public String toString()
{
return "Supplier: number=" + number +
" name=" + name +
" status=" + status +
" city=" + city + '.';
}
} public class Shipment
{
private String partNumber;
private String supplierNumber;
private int quantity;
public Shipment(String partNumber, String supplierNumber, int quantity)
{
this.partNumber = partNumber;
this.supplierNumber = supplierNumber;
this.quantity = quantity;
}
public final String getPartNumber()
{
return partNumber;
}
public final String getSupplierNumber()
{
return supplierNumber;
}
public final int getQuantity()
{
return quantity;
}
public String toString()
{
return "Shipment: part=" + partNumber +
" supplier=" + supplierNumber +
" quantity=" + quantity + '.';
}
}