JDO 2 allows fields of a class to be defined as embedded, meaning that they are stored in the same table
as the object itself. JPOX supports definition of PersistenceCapable objects as embedded. The implementation
of this functionality is described below.
When a ClassTable is created for a class and it detects a PersistenceCapable field that is embedded
the mapping created is an EmbeddedPCMapping. This provides methods for extraction of the embedded object
from a ResultSet, and for population of a PreparedStatement using the fields of the embedded object. The
EmbeddedPCMapping is created with one datastore column for each field that needs persisting to the
owner's table. In addition, the EmbeddedPCMapping has a series of JavaTypeMappings to represent the fields
of that embedded object's class.
The StateManager plays a crucial role in the management of embedded objects. When an embedded object
is encountered a StateManager is allocated (using its own constructor in the StateManager class).
The StateManager of an embedded object has at least one "embedded owner". This is the StateManager
of the object that contains the embedded object (and the field within that class). This allows embedded
objects to report dirty changes back to the parent object so that it knows when to perform an update.
Embedded PersistenceCapable objects can be nested so that you have one embedded contained in another embedded
and so on. In this case, since the StateManager's are linked (via the embedded owners) when a field
in the most nested is changed, it informs its owner, which informs its owner etc until the change reaches
the containing object. It then marks it's field (that has had some small part changed) as dirty. The next time
a flush() is performed the column(s) of the sub-object(s) will be updated. This means that the UPDATE statement
will contain all columns for the sub-object(s) even though only 1 maybe has changed. We can consider improving this
in future to just update the affected column, but it is not causing a performance issue since the number
of SQL statements is still only 1.
