Washington, September 15-18, 1999 – London, November 21-24, 1999

Object Creation

Ash Rofail

As objects instance data is read from persistence, the CAssociation structure will be built. This will be a public member of the database object. When the object is updated and it's a new instance, it's this structure that will be interrogated to determine what entities to generate INSERT statements for. The recordset that the POM object is based upon will have to be requeried after running the INSERT statements, and the new information returned to CPOMMetaData.

The following example is intended to model the upper end of complexity that will be involved in the definition of a single POM object. The root object is defined as the entity whose RowID is the member of the POM object whose coding name is OID.

The POM object members mapping to the entities on the '1' end of this model would be for information and display purposes only. The real 'meat' of this POM object would be focused on the members mapping to LineItem and Detail.

The CAssociation structure would hold the following information about this POM object:

<root> LineItem

LineItem to Invoice     Many to One

LineItem to Item        Many to One

LineItem to Detail      One To One

Detail to Colors        Many to One

Items to ProductLine    Many to One

Invoice to Customers    Many to One

When an attempt is made to create a new instance of this POM object, the CAssociation structure would be queried for the root entity. An INSERT statement would be generated for all members that map to that entity. Then all relationships to other entities that the root entity was the source of would be examined. When the one-to-one relationship to Details was found, an INSERT statement would be generated for all members that map to that entity. The same OID would be used as was used for LineItem. This entity's relationships would also be examined. Since it's in no creatable relationship to another entity, the creation of this object would be complete. The recordset that this object's data is stored in would be requeried with the new OID as criteria.

The action taken for different entities when creating POM objects will be defined by the rules following for different relationships between entities:

One to Many

A POM object is made up of an members that map to an Invoice entity, but a LineItemPrice member maps to an attribute in the LineItem entity.

Will be read-only and non-creatable

One to one

A LineItem POM object carries some additional information when the ItemType is Clothing. Since this information is only stored for some LineItems, the members corresponding to this additional information map to the Details entity instead of the LineItem entity. There is at most one row in the Details entity for each row in the LineItem entity.

When the object is new, an OID will be generated and separate INSERT statements will be generated for each of the two entities in one-to-one relation. The same OID will be used in both entities. These two statements are executed in a transaction and the recordset requeried. In the meta-data of this object only the root entity's OID should be carried. Which entity is defined as the root entity will depend on the object and implementation requirements or preferences.

Many to One

A POM object is made up of members that map to an LineItem entity, and a member also maps to the InvoiceDate attribute of an Invoice entity.

When the object is new, an insert statement will be built with all the columns from the entity on the many side of the relationship. The recordset should be requeried after this. The OID will be generated in the usual manner. The object on the one side will not be created in this context, as fields from it should be display and information purposes only. Updating this object and its subsequent refresh will cause the members mapping to these attributes to be populated.

Many to many

One patient has many doctors, and one doctor has many patients. To model this an entity is created that carries a patient OID and a doctor OID, as well as its own. Any POM object that carries the OID from this entity as well as attributes from the Patient or Doctor entities would be using schema in  many-to-many relationship.

In this case the root object must be the many-to-many reconciliation table (the OID of the object must come from that table). If the OID comes from either of the entities in many-to-many relation to one another, the object is a one-to-many, and thusly not creatable. When the root object is appropriate for a many-to-many, the root object's fields are compiled into an INSERT statement. This is executed and the recordset requeried.

The following classes will be added to DBLib to support this functionality:

CAssociation

public RootEntityName as String

m_colEntityAssociations

collection of CEntityAssociations objects

CEntityAssociations

public EntityName as String

m_colEntityAssociations

collection of CEntityAssociation objects

CEntityAssociation

public enmAssocOrdinality as EAssocOrdinality

public TargetEntityName as String

The private method BuildJoinCondition of CPOMADOSQL can be modified to add elements to this structure as they're exposed through the generation of SQL.