DataGraph schema

DataGraph schema created by the EJB mediator

The schema created by the mediator for a query consists of an Eclass for each query statement. The name of the Eclass is the Abstract Schema Name (ASN) of the EJB. The Eattributes of the Eclass correspond to the container-managed persistence (CMP) fields or expressions returned by the query statement.

For static DataObjects, the Eclass name can be different provided that the Map argument is used on the createMediator call.

Each EJB relationship specified in the FROM or XREL clause adds an Ereference into the schema. EJB relationships can be unidirectional or bidirectional. However, all Ereferences are defined as bidirectional as this is needed to efficiently navigate the DataGraph on update. An inverse relationship name is generated in the case of a unidirectional EJB relationship. A generated name is of the format <ASName_source><ASName_target>. For example, if the ASNames are EmpBean and DeptBean, and the unidirectional relationship is dept going from EmpBean to DeptBean, the generated inverse name is DeptBeanEmpBean . If no ECLass argument is used on createMediator, then the mediator creates a DataGraph schema with the following characteristics:

the DataObject Eclass names are the corresponding EJB Abstract Schema Names (ASN)
the DataObject attributes names and types are the expression names and types in the query SELECT clauses
the DataObject reference names and types come from the EJB relationships referenced in the FROM clauses.

A "dummy" DataObject with the Eclass name of DataGraphRoot is also created and has containment reference to all the DataObjects. The reference is multivalued, using the EJB ASN name.

DataObject root =  m.getGraph( parms );
root.getType().getName();   // this would return the string "DataGraphRoot"

List depts = (List) root.get("DeptBean");   
// the list of all DeptBean SDOs in the DataGraph 
List emps = (List) root.get("EmpBean");  
// the list of all EmpBean SDOs in the DataGraph

DataGraph containment patterns

References between Service Data Objects (SDO) can be defined as containment references, in which case when an SDO is deleted the delete is cascaded to all of the contained SDO. Also, when the DataGraph is serialized as an XML document, the contained SDO are nested within the parent SDO. Noncontained references are expressed as path expressions in the XML document.

Containment must be defined in the DataGraph schema. When the mediator defines the schema, the root SDO ( named DataGraphRoot) contains all other SDO. EJB relationships are defined as noncontained SDO references. When the caller defines the DataGraph schema, there are three patterns.

ROOT_CONTAINS_ALL: In this pattern there is a dummy SDO that is the root. It is a dummy in the sense that it does not correspond to any EJB. Its purpose is to contain all other SDOs. If the mediator generates the graph schema, the dummy root has a class name of DataGraphRoot and it will have containing references whose names are the EJB ASN names. If the caller uses static schema, the root can have any name. The Eclass of the root is passed on the createMediator call.
ROOT_CONTAINS_SOME: This pattern is applicable only for static schema. There is still a dummy SDO that is the graph root. Other SDO must either be contained by the Ereference that corresponds to the EJB relationship used in the query statement or the SDO must be contained by the dummy root.
NO_DUMMY ROOT: This pattern is applicable only for static schema. There is no dummy root. The root SDO corresponds to the first query statement which must return only a single instance. Non-root SDOs must be contained by the Ereference corresponding to the EJB relationship used in the query statement.