gnue/geas/doc odmg.txt

[Daniel E. Baumann]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Daniel E. Baumann <address@hidden>      02/04/20 00:41:54

Modified files:
        geas/doc       : odmg.txt 

Log message:
        Misc fixes to ODMG notes.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/geas/doc/odmg.txt.diff?tr1=1.12&tr2=1.13&r1=text&r2=text

Patches:
Index: gnue/geas/doc/odmg.txt
diff -c gnue/geas/doc/odmg.txt:1.12 gnue/geas/doc/odmg.txt:1.13
*** gnue/geas/doc/odmg.txt:1.12 Wed Mar 27 00:04:38 2002
--- gnue/geas/doc/odmg.txt      Sat Apr 20 00:41:54 2002
***************
*** 10,17 ****
    can be related to each other, and how objects can be named and
    identified
    - Object Definition Language (ODL) is used to specify application
!   object models 07 is also used to explain the constructs of the
!   Object Model
    - Object Model specifies constructs supported by ODMS:
  
      - basic modeling primitives are the *object* and *literal*, each
--- 10,17 ----
    can be related to each other, and how objects can be named and
    identified
    - Object Definition Language (ODL) is used to specify application
!   object models and is also used to explain the constructs of the
!   Object Model defined here
    - Object Model specifies constructs supported by ODMS:
  
      - basic modeling primitives are the *object* and *literal*, each
***************
*** 59,65 ****
    objects, Class Person defines both the abstract behavior and the
    abstract state of Person objects, the struct Complex defines only
    the abstract state of Complex number literals, in addition to the
!   struct definition and the primitive literal 0 (boolean, car,
    short, long, float, double, octet, and string), ODL defines
    declarations for user-defined collection, union, and enumeration
    literal types.
--- 59,65 ----
    objects, Class Person defines both the abstract behavior and the
    abstract state of Person objects, the struct Complex defines only
    the abstract state of Complex number literals, in addition to the
!   struct definition and the primitive literal 0 (boolean, char,
    short, long, float, double, octet, and string), ODL defines
    declarations for user-defined collection, union, and enumeration
    literal types.
***************
*** 98,104 ****
      behavior 
      - e.g, a Employee might have an operation for calculate_paycheck
      - Salaried_Employee and Hourly_Employee might each refine that
!     behavior to 0 specific needs
      - polymorphic nature of object programming would enable to correct
      behavior to be invoked at runtime, dependent on the actual type of
      the instance
--- 98,104 ----
      behavior 
      - e.g, a Employee might have an operation for calculate_paycheck
      - Salaried_Employee and Hourly_Employee might each refine that
!     behavior to specific needs
      - polymorphic nature of object programming would enable to correct
      behavior to be invoked at runtime, dependent on the actual type of
      the instance
***************
*** 108,127 ****
  
      - ODMG model supports multiple inheritance of object behavior
      - which leaves it possible to inherit operations that have the same
!     - name, but different parameters form 2 interfaces
      - ODMG disallows name overloading during inheritance
      - ODL classes are directly instantiable, interface and types cannot
      be directly instantiated
      - subtyping refers to inheritance of behavior only; consequently
!     - interfaces may only inherit from interfaces and classes may only
!     inherit form interfaces
      - due to ambiguities, interfaces may not inherit from classes nor
      may classes inherit from other classes
   
      Inheritance of State
      ====================
      - ODMG Object Model defines and EXTENDS relationship for the
!     inheritance if state and behavior
      - the EXTENDS also applies to only *object* types, only classes,
      not literals, may inherit state
      - EXTENDS relationship is single inheritance relationship between
--- 108,127 ----
  
      - ODMG model supports multiple inheritance of object behavior
      - which leaves it possible to inherit operations that have the same
!     name, but different parameters from 2 interfaces
      - ODMG disallows name overloading during inheritance
      - ODL classes are directly instantiable, interface and types cannot
      be directly instantiated
      - subtyping refers to inheritance of behavior only; consequently
!     interfaces may only inherit from interfaces and classes may only
!     inherit from interfaces
      - due to ambiguities, interfaces may not inherit from classes nor
      may classes inherit from other classes
   
      Inheritance of State
      ====================
      - ODMG Object Model defines and EXTENDS relationship for the
!     inheritance of state and behavior
      - the EXTENDS also applies to only *object* types, only classes,
      not literals, may inherit state
      - EXTENDS relationship is single inheritance relationship between
***************
*** 153,168 ****
      -  EXTENDS relationship is transitive; consequently every
      ManagerPerson would have a name, a birthDate, a payRate, and a
      boss
!     - not that since class EmployeePerson inherits behavior from (ISA)
      Employee, instances of EmployeePerson and ManagerPerson would
!     all support the behavior 0 within this interface
!     - only legal exception to name 0 occurs when the same
!     property declaration in a class and one of its inherited
      interfaces
!     - since 0 declared within an interface also have a
      procedural interface, such redundant declarations are useful
!     in situations where it is 0 to allow relationships to
!     cross distribution boundaries, yet they also 0 part of the 
      abstract state of the object
      
        Extents
--- 153,168 ----
      -  EXTENDS relationship is transitive; consequently every
      ManagerPerson would have a name, a birthDate, a payRate, and a
      boss
!     - note that since class EmployeePerson inherits behavior from (ISA)
      Employee, instances of EmployeePerson and ManagerPerson would
!     all support the behavior defined within this interface
!     - only legal exception to name-overloading prohibition occurs when the 
same
!     property declaration occurs in a class and in one of its inherited 
      interfaces
!     - since properties declared within an interface also have a
      procedural interface, such redundant declarations are useful
!     in situations where it is desirable to allow relationships to
!     cross distribution boundaries, yet they also constitute part of the 
      abstract state of the object
      
        Extents
***************
*** 174,180 ****
        - if type A is subtype of type B, then extent of A is a subset
        of the extent of B
        - relational DBMS maintains an extent for every defined table
!       - 2 schema designer can decide whether the system should
        automatically maintain the extent of each type
  
        Keys
--- 174,180 ----
        - if type A is subtype of type B, then extent of A is a subset
        of the extent of B
        - relational DBMS maintains an extent for every defined table
!       - ODMS schema designer can decide whether the system should
        automatically maintain the extent of each type
  
        Keys
***************
*** 183,190 ****
        identified by the values they carry for some property or set of
        properties
        - these identifying properties are called *keys*
!       - in relational model, properties are called *candidate
!       keys*
        - a *simple key* consists of a single property
        - a *compound key* consists of a set of properties
        - the scope of uniqueness is the extent of the type; type must
--- 183,189 ----
        identified by the values they carry for some property or set of
        properties
        - these identifying properties are called *keys*
!       - in relational model, properties are called *candidate keys*
        - a *simple key* consists of a single property
        - a *compound key* consists of a set of properties
        - the scope of uniqueness is the extent of the type; type must
***************
*** 250,256 ****
          void    delete();
        };
  
!     - default ODMG locking policy is implicit, all ODMG object support
        explicit locking operations
      - IntegrityError exception is raised by operations on
        relationships and signifies that referential integrity has
--- 249,255 ----
          void    delete();
        };
  
!     - default ODMG locking policy is implicit, all ODMG objects support
        explicit locking operations
      - IntegrityError exception is raised by operations on
        relationships and signifies that referential integrity has
***************
*** 277,283 ****
      - an OID is commonly used as a means for one object to reference
      another
      - literals do not have their own identifiers and cannot stand
!     alone as objects; they are embedded in objects can cannot be
      individually referenced
      - literals values are described as being constant
      - literals are *immutable*; objects are *mutable*
--- 276,282 ----
      - an OID is commonly used as a means for one object to reference
      another
      - literals do not have their own identifiers and cannot stand
!     alone as objects; they are embedded in objects and cannot be
      individually referenced
      - literals values are described as being constant
      - literals are *immutable*; objects are *mutable*
***************
*** 306,312 ****
  
      Object Lifetimes
      ================
!     - 2 life times are supports in the Object Model:
        - transient
        - persistent
      - *transient* is allocated memory that is managed by the
--- 305,311 ----
  
      Object Lifetimes
      ================
!     - 2 life times are supported in the Object Model:
        - transient
        - persistent
      - *transient* is allocated memory that is managed by the
***************
*** 373,380 ****
         // traversals on all collections and bidirectional traversals of
         // ordered collections
         Iterator              create_iterator(in boolean stable);
!        BidirectionalIterator create_bidirectional_iterator(in boolean
!        stable) raises(InvalidCollectionType);
  
         // These methods are used to evaluate OQL predicates upon a the
         // contents of a collection. The boolean results of 'query' and
--- 372,379 ----
         // traversals on all collections and bidirectional traversals of
         // ordered collections
         Iterator              create_iterator(in boolean stable);
!        BidirectionalIterator create_bidirectional_iterator(in boolean stable) 
!                                                   
raises(InvalidCollectionType);
  
         // These methods are used to evaluate OQL predicates upon a the
         // contents of a collection. The boolean results of 'query' and
***************
*** 564,570 ****
        operation inserts the specified object at the end of the list,
        semantics of this operation are equivalent to
        'insert_element_last', 'remove_element' operation removes the
!       first occurrence of the specified object form the list
  
      Array Objects
      =============
--- 563,569 ----
        operation inserts the specified object at the end of the list,
        semantics of this operation are equivalent to
        'insert_element_last', 'remove_element' operation removes the
!       first occurrence of the specified object from the list
  
      Array Objects
      =============
***************
*** 670,676 ****
      Structured Objects
      ==================
      - all structured objects support Object ODL interface
!     - ODMG Object Model support the following types:
  
        * Date 
        * Interval
--- 669,675 ----
      Structured Objects
      ==================
      - all structured objects support Object ODL interface
!     - ODMG Object Model supports the following types:
  
        * Date 
        * Interval
***************
*** 900,906 ****
  
            Time      subtract_interval(in Interval an_interval);
  
!           Time      subtract_time(in Time a_time);
          };
  
        Timestamp
--- 899,905 ----
  
            Time      subtract_interval(in Interval an_interval);
  
!           Interval  subtract_time(in Time a_time);
          };
  
        Timestamp
***************
*** 1269,1280 ****
         supports methods to add and remove elements form its traversal
         path collection 
       - in order to facilitate use of ODL objects models in situations
!        where such models may criss distribution boundaries, we define
         the relationship interface in purely procedural terms by
         introducing a mapping rule form ODL relationships to equivalent
         IDL constructions, each language binding will determine exact
         manner in which these constructions are to be accessed
!      -   declarations that occur within classes define abstract state
         for accessing the relationship
       - declarations that occur within interfaces define only the
         operations of the relationship, not the state
--- 1268,1279 ----
         supports methods to add and remove elements form its traversal
         path collection 
       - in order to facilitate use of ODL objects models in situations
!        where such models may cross distribution boundaries, we define
         the relationship interface in purely procedural terms by
         introducing a mapping rule form ODL relationships to equivalent
         IDL constructions, each language binding will determine exact
         manner in which these constructions are to be accessed
!      - declarations that occur within classes define abstract state
         for accessing the relationship
       - declarations that occur within interfaces define only the
         operations of the relationship, not the state
***************
*** 1345,1351 ****
    definition, thus different types can have operations with the same
    name, these are called overloaded operations
    - when an operations is invoked using an overloaded name, a specific
!   operations must be selected for execution
    - this selection, sometimes called operation name resolution or
    operations dispatching, is based on the most specific type of the
    object supplied as the first argument of the actual call
--- 1344,1350 ----
    definition, thus different types can have operations with the same
    name, these are called overloaded operations
    - when an operations is invoked using an overloaded name, a specific
!   operation must be selected for execution
    - this selection, sometimes called operation name resolution or
    operations dispatching, is based on the most specific type of the
    object supplied as the first argument of the actual call
***************
*** 1398,1411 ****
      'relationships' that define the graph of interconnections between
      'meta objects', which are produced, for example, during ODL source
      compilation
!   - while these relationships guarantee referential integrity of th
!     meta object graph, the y do not guarantee its semantic integrity
      or completeness
    - in order to provide operations that programmers can use to
      correctly construct valid schemas, several creation, addition, and
      removal operations are defined that provide automatic linking and
      unlinking of the required relationships and appropriate error
!     recovery in the even of semantic errors
    - all meta object definitions defined below are in the following
      module:
  
--- 1397,1410 ----
      'relationships' that define the graph of interconnections between
      'meta objects', which are produced, for example, during ODL source
      compilation
!   - while these relationships guarantee referential integrity of the
!     meta object graph, they do not guarantee its semantic integrity
      or completeness
    - in order to provide operations that programmers can use to
      correctly construct valid schemas, several creation, addition, and
      removal operations are defined that provide automatic linking and
      unlinking of the required relationships and appropriate error
!     recovery in the event of semantic errors
    - all meta object definitions defined below are in the following
      module:
  
***************
*** 1433,1439 ****
          // Resolves path names within the repository
          MetaObject resolve(in string name) raises(NameNotFound);
   
!         // Removes bindings form the repository
          void       unbind(in string name) raises(NameNotFound);
  
          list<RepositoryObject> children();
--- 1432,1438 ----
          // Resolves path names within the repository
          MetaObject resolve(in string name) raises(NameNotFound);
   
!         // Removes bindings from the repository
          void       unbind(in string name) raises(NameNotFound);
  
          list<RepositoryObject> children();
***************
*** 1444,1452 ****
      ========
      - visitors provide a convenient "double dispatch" mechanism for
      traversing the meta objects in the repository
!     - to utilize this mechanism a client must implement a
!     RepositoryObjectVisitor object that responds to the
!     visit_... callbacks in an appropriate manner
      - then, by passing this visitor to one of the meta objects in the
      repository, an appropriate callback will occur that may be used as
      required by the client object
--- 1443,1451 ----
      ========
      - visitors provide a convenient "double dispatch" mechanism for
      traversing the meta objects in the repository
!     - to utilize this mechanism a client must implement a 
!     RepositoryObjectVisitor object that responds to the visit_... callbacks in
!     an appropriate manner
      - then, by passing this visitor to one of the meta objects in the
      repository, an appropriate callback will occur that may be used as
      required by the client object
***************
*** 1648,1654 ****
        Constants
        =========
        - constants provide a mechanism for statically associating values with
!       names in the he repository
        - value is defined by the an Operand subclass that is either a literal
        value (Literal), a reference to an another constant (ConstOperand), or 
the
        value of a constant expression (Expression)
--- 1647,1653 ----
        Constants
        =========
        - constants provide a mechanism for statically associating values with
!       names in the repository
        - value is defined by the an Operand subclass that is either a literal
        value (Literal), a reference to an another constant (ConstOperand), or 
the
        value of a constant expression (Expression)
***************
*** 1754,1760 ****
  
               Interfaces
               ==========
!              - most important types in he repository, define abstract behavior
               of application objects and contain operations for creating and
               removing Attributes, Relationships, and Operations within
               themselves
--- 1753,1759 ----
  
               Interfaces
               ==========
!              - most important types in the repository, define abstract 
behavior
               of application objects and contain operations for creating and
               removing Attributes, Relationships, and Operations within
               themselves
***************
*** 1860,1866 ****
               - ScopedType is abstract interface that consolidates the
               mechanisms for its subclasses Enumeration, Structure, and
               Union
!              - Enumerations contain Constants, Structured contain
               Members, and Unions contain UnionCases
               - Unions also have a relationship to a switch_type that
               defines the descriminator of the union
--- 1859,1865 ----
               - ScopedType is abstract interface that consolidates the
               mechanisms for its subclasses Enumeration, Structure, and
               Union
!              - Enumerations contain Constants, Structures contain
               Members, and Unions contain UnionCases
               - Unions also have a relationship to a switch_type that
               defines the descriminator of the union
***************
*** 1974,1980 ****
    ===============================
    - ODMG Object Model uses a conventional lock based approach to to
    concurrency control
!   - approach procides mechanism for enforcing shared or exclusive
    access to objects
    - ODMS grants a lock only if no conflicting locks exist
    - as a result access to persistent objects is coordinated across
--- 1973,1979 ----
    ===============================
    - ODMG Object Model uses a conventional lock based approach to to
    concurrency control
!   - approach provides mechanism for enforcing shared or exclusive
    access to objects
    - ODMS grants a lock only if no conflicting locks exist
    - as a result access to persistent objects is coordinated across
***************
*** 2061,2067 ****
      Transactions and Processes
      ==========================
      - ODMG Object model assumes a linear sequence of transactions
!     executing within a thread of control;i.e., there is one current
      transaction for a thread, and that transaction is implicit in that
      thread's operations
      - if transaction shared by multiple threads in an address space,
--- 2060,2066 ----
      Transactions and Processes
      ==========================
      - ODMG Object model assumes a linear sequence of transactions
!     executing within a thread of control, i.e., there is one current
      transaction for a thread, and that transaction is implicit in that
      thread's operations
      - if transaction shared by multiple threads in an address space,
***************
*** 2071,2077 ****
      - transactions run against a single logical ODMS, not a single
      logical ODMS may be implemented as one or more physical persistent
      stores, possibly distributed on a network
!     -  in the current object model transient objects are not subject
      to transaction semantics, which means aborting a transaction does
      not restore the state of the modified transient objects
  
--- 2070,2076 ----
      - transactions run against a single logical ODMS, not a single
      logical ODMS may be implemented as one or more physical persistent
      stores, possibly distributed on a network
!     - in the current object model transient objects are not subject
      to transaction semantics, which means aborting a transaction does
      not restore the state of the modified transient objects
  
***************
*** 2100,2107 ****
          // closed. An explicit 'begin' operation is required to open a 
          // transaction. If the transaction is already open, and additional 
calls
          // to 'begin' operations raise the 'TransactionNotInProgress' 
exception
!         void begin() raises(TransactionNotInProgress),
!                  DatabaseClosed);
  
          // Causes all persistent objects created or modified during the
          // transaction to be written to the ODMS and to become accessible to
--- 2099,2105 ----
          // closed. An explicit 'begin' operation is required to open a 
          // transaction. If the transaction is already open, and additional 
calls
          // to 'begin' operations raise the 'TransactionNotInProgress' 
exception
!         void begin() raises(TransactionNotInProgress, DatabaseClosed);
  
          // Causes all persistent objects created or modified during the
          // transaction to be written to the ODMS and to become accessible to
***************
*** 2123,2129 ****
          // begin operation, except that locks held by the Transaction object 
are
          // not released, Therefore, it causes all modified objects to be
          // committed to the ODMS, and it retains all locks held by the 
!         //  Transaction object The Transaction object remains open. The 
          // TransactionNotInProgress exception is raised if a checkpoint
          // operation  executed on a closed Transaction object
          void checkpoint() raises(TransactionNotInProgress);
--- 2121,2127 ----
          // begin operation, except that locks held by the Transaction object 
are
          // not released, Therefore, it causes all modified objects to be
          // committed to the ODMS, and it retains all locks held by the 
!         // Transaction object The Transaction object remains open. The 
          // TransactionNotInProgress exception is raised if a checkpoint
          // operation  executed on a closed Transaction object
          void checkpoint() raises(TransactionNotInProgress);
***************
*** 2142,2149 ****
          // between them. To associate the current thread with another
          // Transaction object, simply execute a join on the new Transaction
          // object If necessary, a leave operation is automatically executed to
!         // dissociate  the current thread from its current Transaction
!         // object. Moving form one transaction object to another does not 
commit 
          // or abort a Transaction object. When the current thread has no 
current
          // transaction object, the leave operation is ignored.
          void leave() raises(TransactionNotInProgress);
--- 2140,2147 ----
          // between them. To associate the current thread with another
          // Transaction object, simply execute a join on the new Transaction
          // object If necessary, a leave operation is automatically executed to
!         // dissociate the current thread from its current Transaction
!         // object. Moving from one transaction object to another does not 
commit 
          // or abort a Transaction object. When the current thread has no 
current
          // transaction object, the leave operation is ignored.
          void leave() raises(TransactionNotInProgress);
***************
*** 2199,2205 ****
        // executed within the scope of a Transaction. If not, a 
        // TransactionNotInProgress exception will be raised.
        void open(in string odms_name) raises(DatabaseNotFound, DatabaseOpen);
!       void close() raises(DatabaseClosed, TransactionNotInProgress);
  
        // A name is bound to an object using the bind operation.
        void bind(in Object an_object, in string name)
--- 2197,2203 ----
        // executed within the scope of a Transaction. If not, a 
        // TransactionNotInProgress exception will be raised.
        void open(in string odms_name) raises(DatabaseNotFound, DatabaseOpen);
!       void close() raises(DatabaseClosed, TransactionInProgress);
  
        // A name is bound to an object using the bind operation.
        void bind(in Object an_object, in string name)