Deprecated feature

Physical data container

The physical data container supports create, read, update, delete operations on the physical SDOs, which are mapped directly to the physical schema. It also enables the business logic to work with physical SDOs that are not mapped to the logical model – for example, statistics or auditing data.

An instance of the PhysicalDataContainer can be used to:
  • Retrieve a collection of physical data objects corresponding to the query associated with this instance, using the getPhysicalObjects() method. The order of the physical data objects is consistent with the order of the objects returned by the XPath to SQL query.
  • Persist changes made by the caller to these physical data objects.
  • Create and delete objects using the createPhysicalObject() and removePhysicalObject() methods.
  • Generate a primary key using getNextPrimaryKey() method.
  • Get paging information:
    Returns the total number of results for a paging search
    Indicates if you have reached the last page of the paging search.
    Returns the starting record number which the caller passed in.
  • Saves any changes made to the data objects, by using the method.

Each service module can obtain a service module-specific instance of the DataServiceFacade object via the static getInstance() method and then get an instance of the PhysicalDataContainer for a given query. The DataServiceFacade provides a single front to the persistence layer for a service module. The client can either work with physical data objects directly, or use the business object mediators to transform nouns and noun parts to and from the database in a consistent way.

Key management

Whenever you create a new physical SDO, you need to initialize the value of the primary key on the SDO. You use the physical data container to get the next primary key for a given class, by calling the getNextPrimaryKey(Class aClass) method. This method gets the unique key for a database table represented by the given class. The mapping between the physical table name and class name is defined by the object-relational mapping, as described in Object-relational metadata.