Object oriented data store integration environment for integration of object oriented databases and non-object oriented data facilities

Abstract

A method and apparatus for accessing and effectively integrating non-object oriented data stores with object applications. An integrating environment is implemented wherein an application using a distributed object database and object database management system (ODBMS) is provided with an interface to external data stores in a manner so as to effect location transparency. The application, accessing data via the ODBMS, can manipulate data in foreign data stores which include external data that is mapped and converted into objects for use by object applications. A storage management application program interface ("SM API"), effects a functional interface for handling objects, referencing objects, implementing iteration and indexing of objects, and implementing object transaction and cache handling. The SM API is part of a modular architecture that includes an external storage manager which implements classes that provide the foundation for engaging external data stores, and which maps and converts external data into objects that can be manipulated by an application using the ODBMS.

Claims

What is claimed is:

1. Apparatus for integrating non-object structured data, stored in an external data store having an external data store interface, with at least one object application which processes object data structures through an ODBMS application interface, comprising:

a storage manager mechanism responsive to said ODBMS application interface and said external data store interface, including,

a first interface, between said ODBMS application interface and said storage manager mechanism, said first interface comprising a plurality of first interface constructs including objects, references, indices, extensions and transactions, and facilitating handling of said plurality of first interface constructs for communicating with said ODBMS application interface to transfer object data structures between said storage manager mechanism and said at least one object application;

an integral mapping mechanism responsive to said first interface and receiving at least some of said plurality of first interface constructs, said mapping mechanism mapping said at least some of said plurality of first interface constructs to a plurality of second interface constructs to effect transformation of object data structures to non-object structured data for storage in said external data store and to effect transformation of non-object structured data to object data structures for use by said at least one object application; and

a second interface between said mapping mechanism and said external data store, said second interface comprising said plurality of second interface constructs and facilitating handling of said plurality of second interface constructs for communicating with said external data store interface to transfer non-object structured data between said storage manager mechanism and said external data store.

2. The apparatus of claim 1 wherein said external data store is at least one relational database.

3. The apparatus of claim 1 wherein said storage manager mechanism includes a repository storing information for mapping said at least some of said plurality of first interface constructs to at least some of said plurality of second interface constructs.

4. The apparatus of claim 3 wherein said repository includes schema information describing the structure of data stored in said external data store.

5. The apparatus of claim 2 wherein said second interface communicates directly with said external data store and said plurality of second interface constructs includes a key construct which identifies a particular record in said external data store.

6. The apparatus of claim 2 wherein said second interface communicates directly with said external data store and said plurality of second interface constructs includes a typemap construct which defines the transformation between non-object structured data and object data structures.

7. The apparatus of claim 2 wherein said second interface communicates directly with said external data store and said plurality of second interface constructs includes a typemap construct which defines the transformation between non-object structured data and object data structures, and a key construct which identifies a particular record in said external data store.

8. The apparatus of claim 7 wherein each said typemap construct includes key layout information for constructing a respective key construct from key data stored in said external data store.

9. The apparatus of claim 7 wherein each said typemap construct includes object layout information used in constructing a respective object from object layout data stored in said external data store.

10. The apparatus of claim 3 wherein said repository includes a database management system managing the information in said repository.

Description

FIELD OF THE INVENTION

The present invention relates to computer databases, and more particularly to integration of object oriented databases and non-object oriented data facilities.

BACKGROUND OF THE INVENTION

Various means and methodologies exist presently for persistent storage of data for use in computer system applications. Known database management systems (DBMS's) facilitate storage of data in non-volatile storage, e.g. disks, tapes, etc, for use even after the program that used or generated the data is terminated ("persistence"). In addition to persistence, DBMS's fundamentally provide "concurrency control" so users of data can share a database without interfering with each other or compromising the integrity of data, and "recovery" features to protect and restore data integrity upon system (hardware or software) failures. DBMS "query" facilities enable users to access the large volumes of data within a database by specifying some particular characteristic or field within data records, while "security" features are typically built into DBMS's to limit access to some data. Known DBMS's support "schema management" for describing properties of, and relationships between, data in a database.

With the evolution of DBMS technology, fundamental functionality as described hereinbefore has been maintained and expanded while data complexity and processing performance requirements have increased. A type of data management technology applied in commercial data processing known as "relational" DBMS, is modeled to be relatively simplistic in that all data is organized as though it is formatted into tables, with the table columns representing the table's fields or domains and the table rows representing the values of the table's fields or domains. Data is logically organized as tables but is not necessarily physically stored as such. The relational database user does not need to know how the database is physically constructed and can access and update data via a language interface or "structured query language" (SQL).

The relative complexity of data associated with science and engineering problem solving, and the evolution of complex data structures and data entities modeled on real-world objects led to the development of a new generation of DBM's known as "object DBM's" (ODBM's) or "object oriented DBM's" (OODBM's). ODBM's do not conform to the relational model but provide virtually the same fundamental functionality (i.e. persistence, concurrency control, recovery, security, query facilities and schema management) for storing and manipulating object entities. Object entities or "objects", are complex data structures which model real-world entities, and are associated in classes and identified with their informational features (attributes) and functional features (behaviors). Objects are effected using object oriented programming (OOP) languages such as C++ and Smalltalk. By defining complex, specialized data structures or objects that model real-world entities, program development is made easier and more natural as the level of abstraction of data is raised to a point where applications can be implemented effectively in the same terms in which they are described by the users of the application. Objects are more readily classifiable into types, which are easily related to one another in subtype/supertype hierarchies. OOP languages permit the programmer to flexibly define data types so as not to be constrained by limited predefined types. OOP language types can be associated in classes which can "inherit" attributes and/or behaviors from other classes. Complex object data structures and types are not supported by the relational DBMS model, but by ODBM's which facilitate direct storage and manipulation of objects, without the need to map them into tables.

Relational DBM's and Object DBM's co-exist presently, with little likelihood that one will completely displace the other. Each type of DBMS (i.e. Relational and Object) is best suited for respective particular applications, e.g. Relational for the predefined data types of business data processing such as in the insurance and banking industries; and Object for the extensible data structures modeled on real-world entities such as used in computer-aided design and computer-aided software engineering. However, with the considerable investment associated with existing relational data stores, and the continuing evolution toward and appreciation for object applications, there exists a need for integrating object and relational technologies.

The need for integration of relational and object data typically will arise in situations where new object oriented applications are implemented to take advantage of aspects of object oriented programming in a context where data was/is managed according to the relational model. Known means of integrating object programming with a relational database include doing a manual, programming intensive conversion of all the relational data in the relational DBMS to object data, that is readily accessible to the object oriented programs. However, in addition to the significant efforts required for such conversion, there typically are non-object oriented application programs that continue to require access to the relational data. Thus, disadvantageously, it may be necessary to have redundant data stores resulting in duplicative resources and greater overhead. Additionally the task of updating and maintaining the Relational and Object versions of the DBMS creates difficulties in that updates must be substantially simultaneously coordinated and may have to be replicated in disparate environments. Even if the entire collection of existing programs that access the relational database are rewritten in an object oriented programming language, such a mode of conversion is an expensive, complicated and time consuming endeavor.

Standardized import/export facilities are known which permit importation of data in a predictable input format into an object database. The import/export facility is a program, implementation of which requires knowledge of the schema or format of the relational data. Additionally, the relational data elements must be mapped to objects within an ODBMS which are to be managed by the ODBMS which consequently manages the mapped relational data elements. Such facilities, however, lack flexibility in that a predefined format is required for representing data that is to be passed between relational and object environments. While the import/export facility effectively acts as a translation mechanism, there must be rigid adherence to the predefined format in which the relational data is maintained, otherwise it cannot be mapped to objects and managed by the ODBMS.

Translation techniques in the form of SQL Gateways are known which allow object language programs to retrieve relational data from a relational database in a form approximating objects rather than tables. A programmer must know the organization or schema of the particular data required and is typically limited to use of the data in a format very close to its original relational format. The programmer uses an object oriented programming language to implement a SQL statement or request that acts on the tables of a relational database. The SQL Gateway converts OOP language statements into SQL statements and converts table rows or relational data into objects. Such a mechanism requires the application programmer to be cognizant of and accommodate the technology differences between the relational and object database systems. The programmer must write application code to use the SQL Gateway which requires an understanding of the SQL, and the relational and object oriented paradigms. Gateways do not provide unified access to disparate relational data stores through a single consistent application program interface.

Further, while Gateways provide effective conversion between objects and relational data structures, they do not support a means for identifying objects, which makes it difficult to determine if a data request by an application can be satisfied by data already cached. This can result in redundant accesses to the data stores negatively impacting application performance, and problems with data replication, both of which require substantial additional overhead and coding in the application to prevent or work around. Also, schema information in Gateways is maintained in the foreign data store in a relational format. Runtime access to such schema information requires additional programming at the application level for such information to be available as OOP language objects.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus for accessing and effectively integrating non-object oriented data stores with object applications. An integrating environment is implemented wherein an application using a distributed object database and object database management system (ODBMS) is provided with an interface to external data stores in a manner so as to effect location transparency. The application, accessing data via the ODBMS, can manipulate data in foreign data stores which include external data that is mapped and converted into objects for use by object applications.

A storage management application program interface (hereinafter referred to as "SM API"), effects a functional interface for handling objects, referencing objects, implementing iteration and indexing of objects, and implementing object transaction and cache handling. The SM API is part of a modular architecture that includes an external storage manager which unifies access to external data stores by implementing a single consistent ODBMS API which is well integrated with OOP language(s). The external storage manager implements classes that provide the foundation for engaging external data stores, and maps and converts external data into objects that can be manipulated by an application using an ODBMS. Keys are used to assign object identities to external data, which allows data that is already cached by an application to be identified by its key and located in cache in response to repeated requests for the same data.

Features of the invention include provision of the capabilities to access external data stores including non-object databases with various paradigms, schemas and file formats, by an object database management system. Application developers can use a single object oriented programming paradigm and focus on the object model of their application domain regardless of the underlying storage facilities used to store data used by the application. User-defined storage management components can be developed for accessing a wide variety of external data stores. The benefits of object technology: flexibility, extensibility and reuse of application code, can be appreciated in object applications interfaced to non-object data stores. The investment in existing databases and file systems is preserved while permitting a shift to object oriented applications.

Other features, advantages and aspects of the invention are explained in: ONTOS DB 3.0 Reference Manual Volume 1 Class Library; ONTOS DB 3.0 Developer's Guide; and ONTOS DB 3.1 External Storage Management Guide, which are all incorporated herein by reference. Reference is also made to portions of ONTOS DB 3.1 Extensible Storage Management Guide as found in the detailed description, below.

DESCRIPTION OF THE DRAWING

The invention will be more fully understood from the following detailed description taken in conjunction with the accompanying drawing in which:

FIG. 1 is a block diagram of a distributed object database having a client-server architecture;

FIG. 2 is a block diagram of a modularly architected integration environment according to the invention;

FIG. 3 is a diagrammatic representation of an object model of object data structures for an example of an implementation of an object oriented data store integration environment according to the invention;

FIG. 4 is a diagrammatic representation of relational data structures of a relational external data store for the example of an implementation of an object oriented data store integration environment according to the invention;

FIG. 5 depicts a sample of information typically held in a repository maintained by an external storage manager according to the invention, and illustrates how such information is connected with schema-level constructs of the object model;

FIG. 6 is a diagrammatic representation of a process of implementing an object query mapped to an RDB query;

FIG. 7 is a diagrammatic representation of how an iterator and associated Typemap object cooperate to extract a result from an RDB query cursor and process it into a key;

FIG. 8 illustrates the process of constructing an object from a key;

FIG. 9 is a diagrammatic representation of storing data in an object in an integration environment according to the invention; and

FIG. 10 is a diagrammatic representation of deletion of an object from the external relational database in an integration environment according to the invention.

DETAILED DESCRIPTION

An illustrative embodiment of integration of non-object data stores may be implemented in a distributed database environment, such as an ODBMS like ONTOS DB a product of ONTOS Inc. assignee of the present invention, which uses a client-server architecture to distribute a database around a network. Such a client-server architecture, as illustrated in FIG. 1, involves an application or program 10 written in an object oriented programming (OOP) language, such as C++ or Smalltalk. The application 10 runs in a process on a workstation in a network, as an application process 12. The application process 12 contains the application or program code 10 and a client portion 14 of the distributed database facilities which is implemented within the classes and functions of the distributed database facilities and is effectively transparent to the application 10.

The application 10, when using the distributed database facilities, communicates via the client portion 14 with another process called a primary server 16 running on another host machine somewhere on the network. The primary server 16 is the primary manager of the distributed database facilities, managing its own database area and communicating with secondary servers 18 which manage other areas of the same distributed database.

When the application 10 requires data, such as objects managed by the distributed database facilities, the objects are requested by the client 14, retrieved by the servers 16, 18 and passed to the client 14. The objects are "activated" into the client application's virtual memory and manipulated as OOP structures, such as C++ structures. The application 10 "deactivates" these objects when it is finished with them, optionally deallocates the memory used by them, and passes them back to the client 14. The client 14 passes the objects back to the servers 16, 18 which put changes to the objects in the respective areas of the distributed database.

Referring now to FIG. 2, the object application 10 uses the distributed database facilities of an ODBMS 20 to perform tasks relating to object handling, reference handling, iteration and indexing, and transaction handling, as described hereinafter. While the application 10 utilizes OOP language statements, typically in C++, as a data manipulation language (DML) to access and manipulate data in the ODBMS, the ODBMS must be provided with an interface to foreign or external data stores 22 to effect the required functionality with respect to non-object data or data that is of a substantially different schema than that associated with the object application.

In the illustrative embodiment including ONTOS DB, a modular architecture is implemented wherein an open storage manager application program interface 24 ("SM API") provides an application program interface (API) or open base class that defines generic protocols and functions for storage management, as described in detail in the referenced materials. The SM API 24 essentially effects a plurality of API's to facilitate object handling, reference handling, iteration and indexing, and transaction handling activities. A wide range of object oriented programming and database management systems can be accommodated according to the invention, as long as they support constructs including objects, references, transactions, and indices and extensions.

The functions comprising the SM APE 24 are set forth in the following text, taken from the ONTOS DB 3.1 Extensible Storage Management Guide, Chapters 3-8.

IMPLEMENTING OBJECT HANDLING

Object handling support

Overview

A client application assigns a storage manager instance to each OC.sub.-- Object instance it uses. The application is thus freed to handle objects at a higher level, since it can rely on the storage managers to handle the low-level storage details. At the higher level, the application uses the OC.sub.-- Object and OC.sub.-- Reference interfaces to determine which objects are stored persistently, in which state, and for how long.

An OC.sub.-- Object's storage manager tracks the object's persistent identity (its OID), its persistent representation (its data values as currently stored), and its persistent location (for example, clustering). It also tracks the following mappings:

Between the in-memory object and references to the object

Between the persistent identity and references to the object

Between the persistent identity and the in-memory object

The storage manager also determines how the object is transferred between memory and persistent storage.

Relation of an object to its storage manager

For the object handling functions to work properly, they must be called on the storage manager instance that manages the object. The term "manages" connotes that the storage manager either determined the original

Object handling functions

The OC.sub.-- StorageManager's object handling interface includes functions to query the status of an OC.sub.-- Object. It also includes manipulation functions to make updates to the in-memory and persistent states of the object and to translate between the two states.

Unimplemented functions

These object handling member functions are pure virtual, so must be implemented by the storage management developer.

Memory allocation

    ______________________________________
    virtual void* allocateObj (long sz, OC.sub.-- Type* the Type,
    OC.sub.-- Object* where, OC.sub.-- Clustering howNear);
    ______________________________________

    ______________________________________
    OC.sub.-- Object* defaultActiveObj (OC.sub.-- Object* obj,
    OC.sub.-- Type* theType, unsigned long objSelfRef);
    ______________________________________

    ______________________________________
    void initializeEntityPiece (OC.sub.-- Entity* ent,
           unsigned long refVal);
    ______________________________________

    ______________________________________
    void initializeInstance (unsigned long refValue,
    char* startOfInstance, OC.sub.-- Type* entType);
    ______________________________________

    ______________________________________
    virtual void* allocatePrim (long sz, OC.sub.-- Type* theType,
    OC.sub.-- Object* where, OC.sub.-- Clustering howNear);
    ______________________________________

    ______________________________________
    8 bits; reserved
              24-bit reference space; value set by storage
    for ONTOS manager
    DB
    FIG. 4-1 32 bit reference value (in OC.sub.-- Reference) or
    self reference value (in OC.sub.-- Entity)
    ______________________________________

    ______________________________________
    Exception raised
                    Condition
    ______________________________________
    OC.sub.-- NoSuchRef
                    Reference value is not recognized as
                    valid.
    OC.sub.-- ObjectWasDeleted
                    Referent has been persistently
                    deleted.
    OC.sub.-- WaitException
                    Acquiring a lock on the referent
                    causes the application's current
                    transaction to wait for another
                    transaction to commit.
    OC.sub.-- TransactionWasAborted
                    Acquiring a lock on the referent
                    causes the transaction to be aborted
    ______________________________________

    ______________________________________
    virtual OC.sub.-- LockType getReferentLockType (
    OC.sub.-- Reference* ref);
    ______________________________________

    ______________________________________
    virtual void lockReferent (OC.sub.-- Reference* ref,
    OC.sub.-- LockType lock);
    ______________________________________

    ______________________________________
    virtual void discardReference (OC.sub.-- Reference* ref,
    OC.sub.-- Boolean persistently);
    ______________________________________

    ______________________________________
    virtual OC.sub.-- Argument getReferentAsArgument (
    OC.sub.-- Reference* ref);
    ______________________________________

    ______________________________________
    Exception raised
                    Condition
    ______________________________________
    OC.sub.-- NoSuchRef
                    Reference's value is not
                    recognized as valid.
    OC.sub.-- ObjectWasDeleted
                    Referent has been persistently
                    deleted.
    OC.sub.-- WaitException
                    Acquiring a lock on the referent
                    causes the application's current
                    transaction to wait for another
                    transaction to commit.
    OC.sub.-- TransactionWasAborted
                    Acquiring a lock on the referent
                    causes the transaction to be
                    aborted.
    ______________________________________

    ______________________________________
    virtual unsigned long translateRefValue (
           OC.sub.-- Entity* referent);
    ______________________________________

    ______________________________________
    virtual unsigned long translateRefValue (
            unsigned long oldRefValue,
            OC.sub.-- StorageManager* oldContext);
    ______________________________________

    ______________________________________
    virtual OC.sub.-- Boolean compareReferences (OC.sub.-- Reference* r1,
    oc.sub.-- Reference* r2);
    ______________________________________

    ______________________________________
    virtual OC.sub.-- Boolean simplifyRefValue (
            unsigned long& simpleRefValue,
            OC.sub.-- StorageManager*& simpleSM);
    ______________________________________

    ______________________________________
    virtual void makePersistentReference (
    unsigned long refValue, OC.sub.-- StorageManager* referencer,
    OC.sub.-- PersistentReference& toBeSet);
    ______________________________________

    ______________________________________
    virtual OC.sub.-- Boolean replacePersistentReference (
    const OC.sub.-- PersistentReference& oldValue,
    const OC.sub.-- PersistentReference& newValue,
    OC.sub.-- StorageManager* owner);
    ______________________________________

    ______________________________________
    virtual unsigned long resolvePersistentReference (
    const OC.sub.-- PersistentReference& toBeResolved,
    OC.sub.-- StorageManager* referencer);
    ______________________________________

    ______________________________________
    void checkIndexesOnType (OC.sub.-- Type* theType)
    OC.sub.-- Object* suspectInstance;
    OC.sub.-- Iterator* theIter = theType.fwdarw.getIterator
    (OC.sub.-- read-Lock);
    while (suspectInstance = (OC.sub.-- Object*)theIter.fwdarw.yield-
    EntityValue ( ) )
    {
    OC.sub.-- StorageManager::checkAllIndexes (suspectInstance);
    }
    }
    ______________________________________

    ______________________________________
    static void removeFromCommonExtension (OC.sub.-- Type* theType,
    OC.sub.-- Object* theObj);
    ______________________________________

    ______________________________________
    static void removeFromAllCommonExtensions (OC.sub.-- Object*
    theObj);
    ______________________________________

    ______________________________________
    static void addToCommonIndex (OC.sub.-- Type* theType,
    OC.sub.-- Property* theProp, OC.sub.-- Object* theObj);
    ______________________________________

    ______________________________________
    static void removeFromCommonIndex (OC.sub.-- Type* theType,
    OC.sub.-- Property* theProp, OC.sub.-- Object* theObj);
    ______________________________________

    ______________________________________
    static void updateCommonIndex (OC.sub.-- Type* theType,
    OC.sub.-- Property* theProp, OC.sub.-- Object* theObj);
    ______________________________________

    ______________________________________
    OC.sub.-- Boolean isIndexParticipant (OC.sub.-- Type* theType,
    OC.sub.-- Property* theProp);
    ______________________________________

    ______________________________________
    void enableIndexParticipation (OC.sub.-- Type* theType,
    OC.sub.-- Property* theProp, OC.sub.-- Boolean ordered,
    OC.sub.-- Boolean isUnique);
    ______________________________________

    ______________________________________
    void disableParticipation (OC.sub.-- Type* theType,
    OC.sub.-- Property* theProp);
    ______________________________________

    ______________________________________
    To use
    #include "External.h"
    Synopsis
    class OC.sub.-- ExternalFreeFormKey : public OC.sub.-- ExternalKey {
    protected:
    OC.sub.-- ExternalFreeFormKey (
    OC.sub.-- Entity* referent = (OC.sub.-- Entity*) 0);
    OC.sub.-- ExternalFreeFormKey (OC.sub.-- APL* theAPL);
    .about.OC.sub.-- ExternalFreeFormKey ( );
    virtual OC.sub.-- Object* getReferent (OC.sub.-- ExternalSM*&,
    OC.sub.-- Type*&, OC.sub.-- LockType);
    virtual OC.sub.-- ExternalSM* getExternalSM ( ) = 0;
    virtual void* getReferenceText (OC.sub.-- ExternalSM*,
    OC.sub.-- LockType) = 0;
    virtual OC.sub.-- Type* getTypeOfObj (void*) = 0;
    virtual OC.sub.-- Object* getProtoObj (void*, OC.sub.-- Type*) =
    0;
    };
    ______________________________________

    ______________________________________
    OC.sub.-- ExternalFreeFormKey (
    OC.sub.-- Entity* referent = (OC.sub.-- Entity*) 0);
    ______________________________________

    ______________________________________
    virtual OC.sub.-- Object* getProtoObj (void* dataStruct,
    OC.sub.-- Type* objType);
    ______________________________________

    ______________________________________
    virtual OC.sub.-- Object* getReferent (OC.sub.-- ExternalSM*& extSM,
    OC.sub.-- Type*& type, OC.sub.-- LockType lock);
    ______________________________________

    ______________________________________
    virtual void* getReferentText (
    OC.sub.-- ExternalSM* extSM, OC.sub.-- LockType lock);
    ______________________________________

    ______________________________________
    To use
    #include "External.h"
    Synopsis
    class OC.sub.-- ExternalIndexIterator : public
    OC.sub.-- External-InstIterator{
    public:
    OC.sub.-- ExternalIndexIterator (OC.sub.-- ExternalTypeMap*
    source,
            OC.sub.-- Type* type, OC.sub.-- Property* prop,
            OC.sub.-- -Argument value,
            OC.sub.-- LockType lock, void* cursorData = 0);
    OC.sub.-- ExternalIndexIterator (OC.sub.-- ExternalTypeMap*
    source,
            OC.sub.-- Type* type, OC.sub.-- Property* prop,
            OC.sub.-- Argument start,
            OC.sub.-- Argument end, OC.sub.-- Boolean yieldInOrder,
            OC.sub.-- LockType lock, void* cursorData = 0);
    virtual OC.sub.-- Boolean moreData ( );
    OC.sub.-- Property* getProperty ( );
    OC.sub.-- Argument getStart ( );
    OC.sub.-- Argument getEnd ( );
    OC.sub.-- Boolean get YieldsInOrder ( );
    OC.sub.-- Boolean getYieldsRange ( );
    };
    ______________________________________

    ______________________________________
    OC.sub.-- ExternalIndexIterator (OC.sub.-- ExternalTypeMap* source,
    OC.sub.-- Type* type, OC.sub.-- Property* prop, OC.sub.-- Argument
    value,
    OC.sub.-- LockType lock = OC.sub.-- defaultLock,
    void* cursorData = 0);
    OC.sub.-- ExternalIndexIterator (OC.sub.-- ExternalTypeMap* source,
    OC.sub.-- Type* type, OC.sub.-- Property* prop, OC.sub.-- Argument
    start,
    OC.sub.-- Argument end, OC.sub.-- Boolean yieldInOrder,
    OC.sub.-- LockType lock = OC.sub.-- defaultLock,
    void* cursorData = 0);
    ______________________________________

    ______________________________________
    source   Pointer to the OC.sub.-- ExternalTypeMap that
             generated this instance.
    type     Pointer to the type of objects the iterator
             returns.
    prop     Pointer to the OC.sub.-- Property over which to iterate.
    value    Value required for prop for the iterator to return
             the object.
    lock     Type of lock for objects in the iteration.
    cursorData
             Optional pointer to an implementation-specific
             object, which contains data for tracking the state
             of the iteration.
    yieldInOrder
             Value OC.sub.-- true yields an index in ascending
             order of the property's value.
    start    First value in a range of indexes.
    end      Last value in a range of indexes.
    ______________________________________

    ______________________________________
    To use
    #include "External.h"
    Synopsis
    class OC.sub.-- ExternalInstIterator : public OC.sub.-- Iterator {
    public:
    OC.sub.-- ExternalInstIterator (OC.sub.-- ExternalTypeMap*
    source,
            OC.sub.-- Type* type, OC.sub.-- LockType lock =
            OC.sub.-- defaultLock,
            void* cursorData = 0);
    virtual OC.sub.-- Boolean moreData ( );
    virtual OC.sub.-- Argument operator ( ) ( );
    virtual OC.sub.-- Entity* yieldEntityValue ( );
    virtual long yieldIntegerValue ( );
    virtual char* yieldStringValue ( );
    virtual double yieldRealValue ( );
    virtual void* yieldPointerValue ( );
    virtual OC.sub.-- Boolean yieldLogicalValue ( );
    virtual char yieldCharacterValue ( );
    virtual void reset (OC.sub.-- LockType lock =
    OC.sub.-- -defaultLock);
    virtual void reset (OC.sub.-- Entity* ent,
            OC.sub.-- LockType lock = OC.sub.-- defaultLock);
    virtual OC.sub.-- Boolean seek (long offset,
    OC.sub.-- SeekType sType);
    protected:
    OC.sub.-- ExternalTypeMap* getSource ( );
    void* getCursorData ( );
    OC.sub.-- Type* getType ( );
    };
    ______________________________________

    ______________________________________
    OC.sub.-- ExternalInstIterator (OC.sub.-- ExternalTypeMap* source,
    OC.sub.-- Type* type, OC.sub.-- LockType lock =
    OC.sub.-- defaultLock,
    void* cursorData = 0);
    ______________________________________

    ______________________________________
    source     Pointer to the OC.sub.-- ExternalTypeMap that
               generated this instance.
    type       Pointer to the type of objects that the iterator
               returns.
    lock       Type of lock for objects in the iteration.
    cursorData Optional pointer to an implementation-specific
               object, which contains data for tracking the
               state of the iteration.
    ______________________________________

    ______________________________________
           virtual void reset (OC.sub.-- Entity* ent,
             OC.sub.-- LockType lock = OC.sub.-- defaultLock);
    ______________________________________

    ______________________________________
    To use
    #include "External.h"
    Synopsis
    class OC.sub.-- ExternalKey : public OC.sub.-- Object {
    protected:
    OC.sub.-- ExternalKey (OC.sub.-- Entity* referent =
    (OC.sub.-- -Entity*) 0);
    OC.sub.-- ExternalKey (OC.sub.-- APL* theAPL);
    .about.OC.sub.-- ExternalKey ( );
    void destroy (OC.sub.-- Boolean aborted);
    virtual OC.sub.-- Type* getDirectType ( );
    virtual unsigned long getReferentHashKey ( ) const;
    virtual unsigned long getEntityHashKey ( ) const;
    virtual OC.sub.-- Boolean operator==(const
    OC.sub.-- Entity& ent)
            const;
    virtual OC.sub.-- Object* getReferent
    (OC.sub.-- ExternalSM*& sm,
            OC.sub.-- Type*& type, OC.sub.-- LockType lock);
    virtual void lockReferent (OC.sub.-- LockType lock);
    virtual void putReferent ( );
    virtual void deleteReferent ( );
    OC.sub.-- Object* getReferentIfActive ( );
    OC.sub.-- LockType getReferentLockType ( );
    OC.sub.-- Boolean getReferentIsNew ( );
    OC.sub.-- Boolean getReferentIsInDB ( );
    void setReferentLockType (OC.sub.-- LockType
    theLock);
    };
    OC.sub.-- ExternalKey (OC.sub.-- Entity* referent =
    (OC.sub.-- Entity*) 0);
    ______________________________________

    ______________________________________
    virtual OC.sub.-- Object* getReferent (OC.sub.-- ExternalSM*& extSM,
    OC.sub.-- Type*& type, OC.sub.-- LockType lock);
    ______________________________________

    ______________________________________
    To use
    #include "External.h"
    Synopsis
    class OC.sub.-- ExternalSM : public OC.sub.-- StorageManager {
    public:
    virtual OC.sub.-- Type* getDirectType ( );
    virtual void putObject (OC.sub.-- Boolean deallocate =
    OC.sub.-- false);
    virtaul void deleteObject (
    OC.sub.-- Boolean deallocate = OC.sub.-- false);
    OC.sub.-- Iterator* getTypeMapIterator (
    OC.sub.-- LockType lock = OC.sub.-- defaultLock);
    virtual OC.sub.-- ExternalTypeMap* getTypeMap
    (OC.sub.-- Type* theType);
    protected:
    OC.sub.-- ExternalSM (char* name = (char*) OC.sub.-- null);
    OC.sub.-- ExternalSM (OC.sub.-- APL* theAPL);
    .about.OC.sub.-- ExternalSM ( );
    void destroy (OC.sub.-- Boolean aborted);
    virtual OC.sub.-- Boolean isReferentActive
    (OC.sub.-- -Reference* ref);
    virtual OC.sub.-- Boolean isReferentModified
    (OC.sub.-- -Reference* ref);
    virtual OC.sub.-- Boolean isReferentNew
    (OC.sub.-- Reference* ref);
    virtual OC.sub.-- Boolean isReferentInDB
    (OC.sub.-- -Reference* ref);
    virtual OC.sub.-- Boolean isReferentDeleted
    (OC.sub.-- -Reference* ref);
    virtual OC.sub.-- Entity* getReferent (OC.sub.-- Reference* ref,
    OC.sub.-- LockType lock);
    virtual OC.sub.-- LockType getReferentLockType (
    OC.sub.-- Reference* ref);
    virtual void lockReferent (OC.sub.-- Reference* ref,
    OC.sub.-- LockType lock);
    virtual void discardReference (OC.sub.-- Reference* ref,
    OC.sub.-- Boolean persistently);
    virtual void* allocateObj (long sz, OC.sub.-- Type* theType,
    OC.sub.-- Object* obj, OC.sub.-- Clustering clustering);
    OC.sub.-- Object* activate (OC.sub.-- Object* obj,
    OC.sub.-- Type* the Type,
    OC.sub.-- ExternalKey* key);
    virtual OC.sub.-- Boolean isObjNew (OC.sub.-- Object* obj);
    virtual OC.sub.-- Boolean isObjInDB (OC.sub.-- Object* obj);
    virtual OC.sub.-- Boolean isObjDeleted (OC.sub.-- Object* obj);
    virtual OC.sub.-- Boolean isObjModified (OC.sub.-- Object* obj);
    virtual void markObjModified (OC.sub.-- Object* obj);
    virtual void unmarkObjModified (OC.sub.-- Object* obj);
    virtual void putObj (OC.sub.-- Object* obj);
    virtual void lockObj (OC.sub.-- Object* obj,
    OC.sub.-- Lock-Type lock);
    virtual OC.sub.-- LockType getObjLockType
    (OC.sub.-- Object* obj);
    virtual void deleteObj (OC.sub.-- Object* obj);
    virtual void destroyObj (OC.sub.-- Object* obj);
    virtual void deallocateObj (void* Obj);
    virtual unsigned long getObjHashKey (OC.sub.-- Object* obj);
    virtual unsigned long translateRefValue (
    OC.sub.-- Entity* referent);
    virtual unsigned long translateRefValue (
    unsigned long oldRefValue,
    OC.sub.-- StorageManager* oldContext);
    virtual OC.sub.-- Boolean compareReferences (
    OC.sub.-- Reference* r1, OC.sub.-- Reference* r2);
    virtual void makePersistentReference (
    unsigned long refValue,
    OC.sub.-- Storage-Manager* forWhom,
    OC.sub.-- PersistentReference& toBeSet);
    virtual unsigned long resolvePersistent-Reference (
    const OC.sub.-- PersistentReference& toBe-Resolved,
    OC.sub.-- StorageManager* forWhom);
    virtual void replacePersistentReference (
    const OC.sub.-- PersistentReference& toBe-Replaced,
    const OC.sub.-- PersistentReference& replacement,
    OC.sub.-- StorageManager* forWhom);
    virtual unsigned long
    getInstanceCount-(OC.sub.-- Type* theType);
    virtual OC.sub.-- Iterator* getIterator (OC.sub.-- Type* theType,
    OC.sub.-- LockType lock);
    virtual OC.sub.-- Iterator* getIterator (OC.sub.-- Type* theType,
    OC.sub.-- Property*, OC.sub.-- Argument value,
    OC.sub.-- LockType lock);
    virtual OC.sub.-- Iterator* getIterator (OC.sub.-- Type* theType,
    OC.sub.-- Property* prop, OC.sub.-- Argument start,
    OC.sub.-- Argument end,
    OC.sub.-- Boolean yieldInOrder, OC.sub.-- LockType lock);
    virtual void startTransaction ( );
    virtual void abortTransaction ( );
    virtual void checkpointTransaction ( );
    virtual void commitTransaction ( );
    virtual void cleanCache ( );
    virtual void beforeKeepCache ( );
    virtual void afterKeepCache ( );
    virtual void closeDatabase (OC.sub.-- Boolean cleanall);
    OC.sub.-- Dictionary* getMaps ( );
    void addTypeMap (OC.sub.-- Type* theType,
    OC.sub.-- ExternalTypeMap* theMap);
    void removeTypeMap (OC.sub.-- Type* theType,
    OC.sub.-- ExternalTyepMap* theMap);
    virtual OC.sub.-- ExternalKey* validateKey
    (OC.sub.-- -ExternalKey* key);
    };
    ______________________________________

    ______________________________________
    void activate (OC.sub.-- Object* obj, OC.sub.-- Type* theType,
    OC.sub.-- ExternalKey* key;
    ______________________________________

    ______________________________________
    void addTypeMap (OC.sub.-- Type* theType,
            OC.sub.-- ExternalTypeMap* theMap);
    ______________________________________

    ______________________________________
    virtual void* allocateObj (long sz, OC.sub.-- Type* type,
    OC.sub.-- Object* obj, OC.sub.-- Clustering clustering);
    ______________________________________

    ______________________________________
    virtual OC.sub.-- Boolean compareReferences (OC.sub.-- Reference* r1,
    OC.sub.-- Reference* r2);
    ______________________________________

    ________