Update operation

The update operation is done by comparing the incoming business object with a business object that is retrieved from the database using the primary keys specified in the top-level, incoming business object.

The adapter performs the following steps when updating a hierarchical business object:
  1. It uses the primary key values of the source business object to retrieve the corresponding entity from the database. The retrieved business object is an accurate representation of the current state of the data in the database.

    If the retrieval fails, indicating that the top-level business object does not exist in the database, the adapter returns a RecordNotFoundException error, and the update fails.

    If the retrieval succeeds, the adapter compares the retrieved business object to the source business object to determine which child business objects require changes in the database. The adapter does not, however, compare values in the source business object’s simple attributes to those in the retrieved business object. The adapter updates the values of all non-key simple attributes.

    If all of the simple attributes in the top-level business object represent keys, the adapter cannot generate an update query for the top-level business object. In this case, the adapter logs a warning and continues to step 2.

  2. It recursively updates all single-cardinality children of the top-level business object.

    If the business object definition requires that an attribute represent a child business object, the child must exist in both the source business object and the retrieved business object. If it does not, the update operation fails, and the adapter returns an error.

    The adapter handles single-cardinality children contained with ownership in one of the following ways:
    • If the child is present in both the source and the retrieved business objects, instead of updating the existing child in the database, the adapter deletes the existing child and creates the new child.
    • If the child is present in the source business object but not in the retrieved business object, the adapter recursively creates it in the database.
    • If the child is present in the retrieved business object but not in the source business object, the adapter recursively deletes it from the database.
    For single-cardinality children contained without ownership, the adapter attempts to retrieve every child from the database that is present in the source business object. If it successfully retrieves the child, the adapter populates the child business object but does not update it, because single-cardinality children contained without ownership are never modified by the adapter.
  3. It updates all simple attributes of the retrieved business object, except those whose corresponding attribute in the source business object is not specified.

    Because the business object being updated must be unique, the adapter verifies that only one row is processed as a result. It returns an error if more than one row is returned.

  4. It processes each multiple-cardinality child of the retrieved business object in one of the following ways:
    • If the child exists in both the source and the retrieved business objects’ arrays, the adapter recursively updates it in the database.
    • If the child exists in the source array but not in the retrieved business object’s array, the adapter recursively creates it in the database.
    • If the child exists in the retrieved business object’s array but not in the source array, the adapter recursively deletes it from the database unless the application-specific information for the attribute that represents the child in the parent has KeepRelationship set to true. In this case, the adapter does not delete the child from the database.

Terms of use |

Last updated: Thu Mar 23 13:24:31 2006

(c) Copyright IBM Corporation 2005.
This information center is powered by Eclipse technology (http://www.eclipse.org)