Relationship Guidelines and Restrictions

• Example one consists of two MBOs:

  Address: addr_id, street, city, country 
  
  Employee: emp_id, name, addr_id (foreign key references Address.addr_id)

  The MBOs have a relationship defined, for example, a composite, uni-directional, one-to-one relationship:

  Employee(Parent) --> Address(Child)

  At runtime, if you delete Employee, Unwired Server attempts to delete the child Address first, which fails because of the Employee.addr_id-to-Address.addr_id reference. For the delete operation to perform as expected, the addr_id foreign key must be defined in the EIS database as on delete set null to enable deletion.

  This requirement applies regardless of the type of relationship defined between the MBOs.

• Example two also uses the Employee and Address MBOs in a relationship that has mutual references:

  Address: addr_id, street, city, country, 
  emp_id(foreign key references Employee.emp_id)
   
  Employee: emp_id, name, addr_id(foreign key references 
  Address.addr_id) 

  You must set both foreign keys in the EIS database as on delete set null or on delete cascade, regardless of the type of relationship you define for Address and Employee, or neither of them can be deleted.

A----->B----->C----->A

• A child object refers to its parent via a foreign key reference from the child to a primary key value in the parent. When modeling your relationships, choose load parameters carefully to load children based on which parents are in the cache, so that foreign key references can always be resolved. At runtime Unwired Server must be able to resolve foreign key references. A poorly modeled relationship could have MBO instances pointed to by foreign keys that have not been loaded into the cache. Examples include:
  • A composite parent that hasn't been loaded which results in the child not being inserted into the cache because composite orphans are not allowed – a child MBO can have multiple parents (many to one), but only one parent can have a composite relationship to the child:

    In a composite relationship, when one child MBO does not have a synchronization parameter, and has multiple parents, each of which has a synchronization parameter, the child inherits synchronization behavior from both of the parents. If a composite relationship does not exist, Unwired WorkSpace randomly selects a parent through which the child synchronizes. Sybase recommends that you define one parent MBO as the composite parent to avoid unintended behavior. For example:

    There are two one-to-many relationships: A<--->>C and B<--->>C. Both MBOs A and B have a synchronization parameter while MBO C has none. In this case, one of the relationships should be a composite.

  • An MBO modeling error where the relationship reference cannot be resolved results in an error message. For example:
    • The Unwired Server log indicates a Null foreign surrogate key value where a child in a non-composite relationship points to a non-existent parent MBO, which could indicate that the MBO is a child in two separate relationships (one composite and one non-composite) and load parameters are improperly configured:

      Serious performance and data integrity issues may ensue. 
      Consider modifying/re-sequencing cache definitions and/or load queries 
      to ensure relationship integrity in the cache.

    • Sybase Control Center error log:

      Composite parent not found

• If a parent MBO's primary key is auto-incremental and you want to perform multi-level insert operations, then the relationship must be composite. Otherwise the child MBO can only be created on an existing parent MBO.
• When Composite is selected, all child operations are performed through the parent.
• MBOs in a composite parent/child relationship where the child is loaded into the Unwired Server cache without a parent (composite orphans) are not supported. For example, a composite relationship between department(parent) and employees(child) that attempts to load employees for which there is no corresponding department is not allowed at runtime. In this scenario you could change the model to use a non-composite relationship or change the MBO model so the application always loads the parent entities before the children.
• Foreign key attributes are updated automatically when setting a related parent/child object. Do not directly update the child's attribute (row) identified by the foreign key.
• Multi-level insert (MLI) operations require composite relationships.
• A composite graph should not span multiple load groups if loading from a structure-oriented EIS.
• A composite graph should not span more than one endpoint definition.

• Subsequent MBOs as child entities (if the relationship mapping is based on a subsequent MBO load argument) are supported, and the relationship is treated the same as a relationship on an attribute, meaning it does not affect MBO loading.
• Relationships from subsequent to first MBOs where the relationship mapping is based on the load argument of the first MBO are not supported.

• A relationship between two local business objects that does not have a primary key set is invalid.