gnue geas/.cvsignore geas/doc/odmg.txt common/s...

[Daniel E. Baumann]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Daniel E. Baumann <address@hidden>      02/02/11 02:35:53

Modified files:
        geas           : .cvsignore 
        geas/doc       : odmg.txt 
Added files:
        common/src/dbdrivers/_pgsql: .cvsignore 
        common/src/dbdrivers/pypgsql: .cvsignore 
        designer/src/forms: .cvsignore 
        designer/src/navigator: .cvsignore 

Log message:
        Update the ODMG notes, ignore some files so my cvs up is purty ;).

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/common/src/dbdrivers/_pgsql/.cvsignore?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/common/src/dbdrivers/pypgsql/.cvsignore?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/designer/src/forms/.cvsignore?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/designer/src/navigator/.cvsignore?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/geas/.cvsignore.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/geas/doc/odmg.txt.diff?tr1=1.4&tr2=1.5&r1=text&r2=text

Patches:
Index: gnue/geas/.cvsignore
diff -c gnue/geas/.cvsignore:1.2 gnue/geas/.cvsignore:1.3
*** gnue/geas/.cvsignore:1.2    Tue Jun 12 07:02:23 2001
--- gnue/geas/.cvsignore        Mon Feb 11 02:35:53 2002
***************
*** 28,33 ****
--- 28,34 ----
  ltconfig
  ltmain.sh
  stamp-h
+ stamp-h1
  stamp-h.in
  stamp.h
  version.h
Index: gnue/geas/doc/odmg.txt
diff -c gnue/geas/doc/odmg.txt:1.4 gnue/geas/doc/odmg.txt:1.5
*** gnue/geas/doc/odmg.txt:1.4  Fri Feb  8 01:14:32 2002
--- gnue/geas/doc/odmg.txt      Mon Feb 11 02:35:53 2002
***************
*** 96,102 ****
      - Associate_Professor is special case of Professor
      - subtype's interface can also be refined to specialize state and
      behavior 
!     - e.g, a Employee might have an operation for claculate_paycheck
      - Salaried_Employee and Hourly_Employee might each refine that
      behavior to 0 specific needs
      - polymorphic nature of object programming would enable to correct
--- 96,102 ----
      - Associate_Professor is special case of Professor
      - subtype's interface can also be refined to specialize state and
      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
***************
*** 188,191 ****
        - 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
!       have an extent to have a key
\ No newline at end of file
--- 188,444 ----
        - 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
!       have an extent to have a key
! 
!   Objects
!   =======
!   - all objects are grouped into an enclosing module that defines a
!   name scope for the types of the model:
! 
!     module ODLTypes
!     {
!       exception DatabaseClosed{};
!       exception TransactionInProgress{};
!       exception TransactionsNotInProgress{};
!       exception IntegrityError{};
!       exception LockNotGranted{};
!   
!       // the following interfaces and classes are defined here
!     };
! 
!     Object Creation
!     ===============
!     - objects created by invoking creation operations on *factory
!     interfaces*
!     - the "new" operation causes the creation of a new instance of an
!     object of the "Object" type
! 
!       interface ObjectFactory
!       {
!         Object new();
!       };
! 
!     - All objects have following ODL interface which is implicitly
!       inherited by all user-defined types
! 
!       interface Object
!       {
!         enum    Lock_Type{read, write, upgrade};
! 
!         // Obtains a specific lock on an object. If an attempt is made
!         // to get a lock on an already locked object, this operation
!         // will block until the specified lock can be acquired, some
!         // time-out threshold is exceeded, or a transaction deadlock is
!         // detected. If the time-out threshold is crossed a 
!         // LockNotGranted exception is raised, If a transaction
!         // deadlock is detected, the transaction deadlock exception is raised.
!          void lock(in Lock_Type mode) raises(LockNotGranted);
! 
!         // Returns TRUE if specified lock was obtained and FALSE if
!         // the lock is in conflict with an existing lock on the object
!         boolean try_lock(in Lock_type mode);
! 
!         // Compares the identity of this object with another
!         boolean same_as(in Object anObject);
! 
!         // Creates a new object that is equivalent to the receiver
!         // object, the new object is not the "same_as" the original object
!         Object  copy();
! 
!         // Explicitly deletes an object from an ODMS by removing it
!         // from memory in addition to the ODMS
!         void    delete();
!       };
! 
!     - default ODMG locking policy is implicit, all ODMG object support
!       explicit locking operations
!     - IntergrityError exception is raised by operations on
!       relationships and signifies that referential integrity has
!       been violated
!     -  access, creation, modification, and deletion of persistent
!       objects must be done within scope of transaction
!     - if attempted outside transaction, TransactionNotInProgress
!       exception is raised
!     - it is assumed that all operations defined on persistent objects
!       have the ability to raise the TransactionNotInProgress exception
! 
!     Object Indentifiers
!     ===================
!     - all objects have identifiers, and object can always be
!     distinguished form all other objects within its *storage domain*
!     - all identifiers in an ODMS are unique, relative to each other
!     - representation of the of an object referred to as an *object
!     identifier*
!     - an object retains the same identifier throughout its entire life
!     time
!     - value of an object's identifier will never change
!     - object remains the same object even if its attribute values or
!     relationships change
!     - 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*
!     - changing values of attributes of an object. or the relationships
!     in which it participates, does not change the identity of the
!     object
!     - OIDs are generated by the ODMS
!     - operation "same_as" is supported, which allows any 2 objects to
!     be compared
!  
!     Object Names
!     ============
!     - an object may be given one or two names that are meaningful to
!     the programmer or end user
!     - ODMS provides a function to map an object name to an object
!     - application can refer at its convience to an object by name;
!     ODMS applies the mapping function to determine the oid that
!     locates the desired object
!     - ODMS expects names to be commonly used by applications to refer
!     to "root" objects, which provide entry points into the ODMS
!     - object name, by contrast, not a defined type interface and does
!     not correspond to an objects property values
!     - scope of uniqueness of names is an ODMS
!     - Object Model does not include a notion of hierarchical names
!     within an ODMS or of name spaces that span ODMSs
! 
!     Object Lifetimes
!     ================
!     - 2 life times are supports in the Object Model:
!       - transient
!       - persistent
!     - *transient* is allocated memory that is managed by the
!     programming language runtime system
!     - when the process/procedure terminates that created the transient
!     object, the memory is deallocated
!     - *persistent* lifetime is allocated memory and storage managed by
!     the ODMS runtime system
!     - these objects continue to exist after the procedure or process
!     that creates them terminates
!     - object lifetimes are independent of type; type may have some
!     instances that are persistent and other that are transient
!     - because ODMG Object Model supports independence of type and
!     lifetime, both persistent and transient objects can be manipulated
!     using the same operations (i.e., OQL)
!     
!     Atomic Objects
!     ==============
!     - an atomic object type is user-defined; there are no built-in
!     atomic object types in the ODMG Object Model
!     
!     Collection Objects
!     ==================
!     - in ODMG Object Model, instances of *collection objects* are
!     composed of distinct elements, each of which can be an instance of
!     an atomic type, another collection, or a literal type
!     - *all* elements of the collection must be of the *same* type
!     - either all the same atomic type or all of the same type of
!     collection, or all of the same literal type
!     - collections supported by ODMG Object Model include:
!       - Set<t>
!       - Bag<t>
!       - List<t>
!       - Array<t>
!       - Dictionary<t,v>
!    - each of these is a type generator, parameterized by the type
!     shown within the angle bracket
!    - all the elements of a Set object are of the same type 't'
!    - all elements of a List object are of the same type 't'
!    - collections are created by invoking operations of the 'factory'
!     interfaces defined for each particular collection
! 
!      interface Collection: Object
!      {
!        exception             InvalidCollectionType{};
!        exception             ElementNotFound{};
! 
!        // Returns the number elements contained in the collection
!        unsigned long         cardinality();
! 
!        // These methods provide means for dynamically querying a collection to
!        // obtain its characteristics
!        boolean               is_empty();
!        boolean               is_ordered();
!        boolean               allows_duplicates();
! 
!        // These methods provide support for element management within a 
collection
!        boolean               contains_element(in Object element);
!        void                  insert_element(in Object element);
!        void                  remove_element(in Object element) 
raises(ElementNotFound);
! 
!        // These methods support the traversal of elements within a
!        // collection. Creates Iterators that support forward-only
!        // 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
!        // 'exists_element' methods indicate whether any elements were
!        // found as a result of performing the OQL query
!        Object                 select_element(in string OQL_predicate);
!        Iterator               select(in string OQL_predicate);
!        boolean                query(in string OQL_predicate, 
!                                     inout Collection result);
!        boolean                exists_element(in string OQL_predicate);
!      };
! 
!     - Collection objects also inherit the operations in the Object
!       interface
!     - identity comparisons are done using the 'same_as' operation
!     - a 'copy' of a Collection returns a new shallow copy of the
!       collection
!     - 'delete' operation removes the collection from the ODMS, and if
!       the collection contains literals, also deletes the contents of
!       the collection, if the collection contains objects, the
!       collection remains unchanged 
! 
!     - an Iterator, which is a mechanism for accessing elements of a
!       Collection object, can be created to traverse the collection
! 
!       interface Iterator
!       {
!         exception NoMoreElements{};
!         exception InvalidCollectionType{};
! 
!         // Determines whether an iteration is safe from changes made
!         // to the collection during iteration, a stable iterator
!         // ensures that modifications made to a collection during
!         // iteration will not effect traversal, if an iterator is not
!         // stable, the iteration only supports retrieving elements from a
!         // collection during traversal, as changes made to the collection
!         // during iteration may result in missed elements or double
!         // processing of an element
!         boolean   is_stable();
! 
!         boolean   at_end();
!   
!         // Repositions the iterator to the first element in the iteration
!         void      reset();
!         
!         // Retrieves the element currently pointed to by the iterator
!         Object    get_element() raises(NoMoreElements);
! 
!         // Increments the iterator to the next element in the iteration
!         void      next_position() raises(NoMoreElements);
! 
!         // This is valid only when iterating over an Array or List, it
!         // replaces the element currently pointed to by the iterator with
!         // the argument object
!         void      replace_element(in Object element)
!                                   raises(InvalidCollectionType);
! 
!       };
! 
!       interface BidirectionalIterator: Iterator
!       {
!         boolean   at_beginning();
! 
!         // Decrements the iterator to the previous element in the iteration
!         void      previous_position() raises(NoMoreElements);
!       };
!