[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gnue/docbook/Proposals/geasarch outline.txt
|
From: |
Daniel E. Baumann |
|
Subject: |
gnue/docbook/Proposals/geasarch outline.txt |
|
Date: |
Sun, 19 May 2002 21:53:47 -0400 |
CVSROOT: /cvsroot/gnue
Module name: gnue
Changes by: Daniel E. Baumann <address@hidden> 02/05/19 21:53:47
Modified files:
docbook/Proposals/geasarch: outline.txt
Log message:
Add Python bindings for relationship delcarations.
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/docbook/Proposals/geasarch/outline.txt.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
Patches:
Index: gnue/docbook/Proposals/geasarch/outline.txt
diff -c gnue/docbook/Proposals/geasarch/outline.txt:1.2
gnue/docbook/Proposals/geasarch/outline.txt:1.3
*** gnue/docbook/Proposals/geasarch/outline.txt:1.2 Mon May 13 01:43:47 2002
--- gnue/docbook/Proposals/geasarch/outline.txt Sun May 19 21:53:47 2002
***************
*** 24,37 ****
a business's data
- Maintainability: The GEAS code base must be maintainable by the
GEAS development team and clear enough to allow interested
! programmers to adapt ot to their needs, fix bugs, or even take over
maintenance of part or all of GEAS
- Configurability: GEAS must support configuration at runtime
(dynamically) and a central location for configuration information
it must be easily configured without programming skills, be
configured without downtime, and in separate "layers" for various
levels of specification
! - Performance: GEAs must perform reasonably well with large numbers
of users and/or large quantities of data
- Database Independence: GEAS must support a number of Database
systems as the backend
--- 24,37 ----
a business's data
- Maintainability: The GEAS code base must be maintainable by the
GEAS development team and clear enough to allow interested
! programmers to adapt to their needs, fix bugs, or even take over
maintenance of part or all of GEAS
- Configurability: GEAS must support configuration at runtime
(dynamically) and a central location for configuration information
it must be easily configured without programming skills, be
configured without downtime, and in separate "layers" for various
levels of specification
! - Performance: GEAS must perform reasonably well with large numbers
of users and/or large quantities of data
- Database Independence: GEAS must support a number of Database
systems as the backend
***************
*** 64,70 ****
Language Design Principles
- ODMG python binding based upon 2 principles: should bind to
python in a natural way which is consistent with principles of the
! langauge, and should support language inertoperability consistent
with ODL specification and semantics
- these principles have several implications that are evident in
the design of the binding
--- 64,70 ----
Language Design Principles
- ODMG python binding based upon 2 principles: should bind to
python in a natural way which is consistent with principles of the
! language, and should support language inertoperability consistent
with ODL specification and semantics
- these principles have several implications that are evident in
the design of the binding
***************
*** 74,85 ****
python binding
2. the binding respects python syntax, meaning the python
! language will not have to be modified to accomodate this
binding. ODL concepts will be represented using normal python
coding conventions
3. binding respects the fact that python is dynamically
! typed. arbitraty python objects may be stored persistently,
including ODL-specified objects that will obey the ODL typing
semantics
--- 74,85 ----
python binding
2. the binding respects python syntax, meaning the python
! language will not have to be modified to accommodate this
binding. ODL concepts will be represented using normal python
coding conventions
3. binding respects the fact that python is dynamically
! typed. arbitrary python objects may be stored persistently,
including ODL-specified objects that will obey the ODL typing
semantics
***************
*** 95,114 ****
part of the mapping required by this document
- section/chapter provides informal descriptions of the IDL
binding topics and more formally defines the python binding for
! the ODL extensions, inclusng relationships, literals and
collections
- ODMG python binding can be automated by an ODL compiler that
processes ODL declarations and generates a graph of 'meta
objects', which model the schema of the database (ODMS)
- the meta objects provide the type information that allows the
! python binding to support the rewuired ODL type semantics
- complete set of such meta objects defines the entire schema of
the database would serve much in the same capacity as an OMG
Interface Repository
- includes python binding for meta object interfaces defined in
ch. 2
! - in sucha repository, the meta objects that represent the schema
! of the database may be programatically accessses and modified by
python applications (clients, etc.), through their standard
interfaces
- one such application, a 'binding generator', may be used to
--- 95,114 ----
part of the mapping required by this document
- section/chapter provides informal descriptions of the IDL
binding topics and more formally defines the python binding for
! the ODL extensions, including relationships, literals and
collections
- ODMG python binding can be automated by an ODL compiler that
processes ODL declarations and generates a graph of 'meta
objects', which model the schema of the database (ODMS)
- the meta objects provide the type information that allows the
! python binding to support the required ODL type semantics
- complete set of such meta objects defines the entire schema of
the database would serve much in the same capacity as an OMG
Interface Repository
- includes python binding for meta object interfaces defined in
ch. 2
! - in such a repository, the meta objects that represent the schema
! of the database may be programatically accesses and modified by
python applications (clients, etc.), through their standard
interfaces
- one such application, a 'binding generator', may be used to
***************
*** 125,131 ****
Mapping the ODMG Object Model Into Python
- although python has a powerful data model that is close to the one
! presented in ch. 2, it remains ncessary to precisely describe how
the concepts of the ODMG Object Model map into concrete python
constructions
--- 125,131 ----
Mapping the ODMG Object Model Into Python
- although python has a powerful data model that is close to the one
! presented in ch. 2, it remains necessary to precisely describe how
the concepts of the ODMG Object Model map into concrete python
constructions
***************
*** 143,149 ****
'Collection' subclass (one-to-many, many-to-many relations)
embedded as an instance variable of the object
- rules for defining sets of accessor methods are presented that
! allow all relationshipsto be managed uniformly
Names
- objects may be named using methods of the Database interface
--- 143,149 ----
'Collection' subclass (one-to-many, many-to-many relations)
embedded as an instance variable of the object
- rules for defining sets of accessor methods are presented that
! allow all relationships to be managed uniformly
Names
- objects may be named using methods of the Database interface
***************
*** 195,211 ****
scoping mechanisms, except that it does not allow for nested
modules
- in addition Python requires each object to be implemented in a
! module; globally visible objects are not suppported
- because of these constraints, scoped names are translated into
Python using the
following rules:
* an IDL module mapped into a Python module, modules containing
modules are
mapped to packages (i.e., directories with an __init__ module
containing all
definitions excluding the nested modules). An implementation can
! chose to map toplevel definitions to modules in an implementation
defined
package, to allow concurrent installations of different ODMG
runtime
libraries. In that case, the implementation must provide
! additional modules so that toplevel modules can be used without
importing them from a package.
* for all other scopes, a Python class is introduced that
--- 195,211 ----
scoping mechanisms, except that it does not allow for nested
modules
- in addition Python requires each object to be implemented in a
! module; globally visible objects are not supported
- because of these constraints, scoped names are translated into
Python using the
following rules:
* an IDL module mapped into a Python module, modules containing
modules are
mapped to packages (i.e., directories with an __init__ module
containing all
definitions excluding the nested modules). An implementation can
! chose to map top-level definitions to modules in an implementation
defined
package, to allow concurrent installations of different ODMG
runtime
libraries. In that case, the implementation must provide
! additional modules so that top-level modules can be used without
importing them from a package.
* for all other scopes, a Python class is introduced that
***************
*** 327,333 ****
Structures
- an IDL struct definition is mapped into a Python class or
type
! - for each field int he struct, there is a corresponding
attribute in the class with the same name as the field
- the constructor of the class expects the field values, from
left to right
--- 327,333 ----
Structures
- an IDL struct definition is mapped into a Python class or
type
! - for each field in the struct, there is a corresponding
attribute in the class with the same name as the field
- the constructor of the class expects the field values, from
left to right
***************
*** 420,426 ****
class QueryInvalidError (QueryError):
! Raised if the query is not a vaild OQL query and thus does not
compile
class QueryParameterCountInvalidError (QueryError):
--- 420,426 ----
class QueryInvalidError (QueryError):
! Raised if the query is not a valid OQL query and thus does not
compile
class QueryParameterCountInvalidError (QueryError):
***************
*** 435,448 ****
class TransactionAbortedError (ODMGRuntimeError):
! Raised when the database system has asyncronously terminated
the user's transaction due to deadlock, resource failure, and
so on. In such cases the user's data is reset just as if the
user had called Transaction.abort.
class TransactionInProgressError (ODMGRuntimeError):
! Raised when attempting to call a method whithin a transaction
that must be called when no transaction is in progress
class TransactionNotInProgressError (ODMGRuntimeError):
--- 435,448 ----
class TransactionAbortedError (ODMGRuntimeError):
! Raised when the database system has asynchronously terminated
the user's transaction due to deadlock, resource failure, and
so on. In such cases the user's data is reset just as if the
user had called Transaction.abort.
class TransactionInProgressError (ODMGRuntimeError):
! Raised when attempting to call a method within a transaction
that must be called when no transaction is in progress
class TransactionNotInProgressError (ODMGRuntimeError):
***************
*** 456,477 ****
with the value of the constant
Operations
! - if operations expects parameters of the IDL Object type, and
! Pyhton obeject representing an object reference might be passed
as an actual argument
! - if an object expects an parameter of an abstract interface,
! either an object implementing that interface or a value
supporting this interface may be passed as an actual argument
- the semantics of abstract values then define whether the
argument is passed by value or by reference
! - operations of an interfacemap to methods available on the
object references
- parameters with a parameter attribute of 'in' or 'inout' are
passed from left to right to the method, skipping 'out'
parameters
! - return value of a method depends on the4 number of 'out'
parameters and the return type
! - if operations returns a value, this value forms the first
'result value'
- all 'inout' or 'out' parameters form consecutive 'result
values'
--- 456,478 ----
with the value of the constant
Operations
! - nil object is represented by 'None'.
! - if operation expects parameters of the IDL Object type, and
! Python object representing an object reference might be passed
as an actual argument
! - if an operation expects a parameter of an abstract interface,
! either an object implementing that interface, or a value
supporting this interface may be passed as an actual argument
- the semantics of abstract values then define whether the
argument is passed by value or by reference
! - operations of an interface map to methods available on the
object references
- parameters with a parameter attribute of 'in' or 'inout' are
passed from left to right to the method, skipping 'out'
parameters
! - return value of a method depends on the number of 'out'
parameters and the return type
! - if the operation returns a value, this value forms the first
'result value'
- all 'inout' or 'out' parameters form consecutive 'result
values'
***************
*** 487,500 ****
interface I
{
oneway void stop();
! bool more_date();
! void get_date(out string name, out long age);
};
a client would write
names={}
! while my_I.more_date():
name,age = my_I.get_data()
names[name]=age
my_I.stop()
--- 488,501 ----
interface I
{
oneway void stop();
! bool more_data();
! void get_data(out string name, out long age);
};
a client would write
names={}
! while my_I.more_data():
name,age = my_I.get_data()
names[name]=age
my_I.stop()
***************
*** 502,508 ****
- if an interface defines an 'attribute name', the attribute is mapped
into an opertaion _get_name, as defined
! - if the attrbute is not 'readonly' there is an additional operation
_set_name, as defined in the 'OMG IDL Syntax and Semantics' chapter,
"Attribute Declaration" section, of the 'Common Object Request Broker:
! Architecture and Specification' document
\ No newline at end of file
--- 503,689 ----
- if an interface defines an 'attribute name', the attribute is mapped
into an opertaion _get_name, as defined
! - if the attribute is not 'readonly' there is an additional operation
_set_name, as defined in the 'OMG IDL Syntax and Semantics' chapter,
"Attribute Declaration" section, of the 'Common Object Request Broker:
! Architecture and Specification' document
!
! Python ODL Binding Extensions
! - section describes binding of ODMG ODL to Python
! - ODL provides a description of the database schema as a set of
! interfaces, including their attributes, relationships, and
! operations
! - Python implementations consist of a set of object classes and
! their instances
! - language binding provides a mapping between these domains
!
! Interfaces and Classes
! - in ODL, interfaces used to represent the 'abstract behavior'
! of and object, and classes used to model the 'abstract state'
! of objects
! ***** to be determined *****
! - add ODLName method that returns the name of the ODL
! interface or class that is bound to the object in the schema
! repository? e.g., aDate.ODLName() returns string '::Date',
! which is name of the odl interface
! - we may not need this because python has a namespace and I
! only see the Smalltalk binding doing this because it does not
! support the concept of namespaces, afaict
! ***** to be determined *****
! - an ODL interface maps to a Python class that raises
! MethodNotImplementedError for the operations of the interface
! class, all other conventions follow the IDL binding for interfaces
! - an ODL class maps to a Python class
!
! Attribute Declarations
! - attribute declarations used to define pairs of accessor
! operations that get and set attribute values
! - Generally, there would be a one-to-one correspondence
! between attributes defined within an ODL class and instance
! variables defined within the corresponding Python class,
! although this is not required
! - ODL attributes define abstract state of their object when
! they appear within class definitions
! - when attributes appear within interface definitions, as in
! IDL they are merely a convenience mechanism for introducing get
! and set accessing operations
! - e.g. attribute Enum Rank {full, associate, assistant} rank;
!
! yields Python methods:
!
! def _get_rank(self):
!
! def _set_rank(self, aProfessorRank):
!
! Relationship Declarations
! - relationships define sets of accessor operations for adding
! and removing associations between objects
! - as with attributes relationships are a part of an object's
! abstract state
! - Python biding for relationships results in public methods to
! "form" and "drop" members from the relationship, plus public
! methods on the relationship target classes to provide access and
! private methods to manage the required referential integrity
! constraints
! - we begin the relationship binding by applying the chapter 2
! mapping rule from ODL relationships to equivalent IDL
! constructions and then illustrate with a complete example:
!
! Single-Valued Relationships
!
! relationship X Y inverse Z;
!
! we expand first to the IDL attribute and operations:
!
! attribute X Y;
! void form_Y(in X target) raises(IntegrityError);
! void drop_Y(in X target) raises(IntegrityError);
!
! which result in the following Python methods:
!
! def Y(self):
!
! def form_Y(self, target):
!
! def drop_Y(self, target):
!
! def __Y(self):
!
! For example, from Chapter 3:
!
! interface Course
! {
! ....
! relationship Professor is_taught_by
! inverse Professor::teaches;
! ...
! }
!
! Expands into the following IDL attributes and operations:
!
! attribute Professor is_taught_by;
!
! void form_is_taught_by(in Professor aProfessor)
! raises(IntegrityError);
!
! void drop_is_taught_by(in Professor aProfessor)
! raises(IntegrityError);
!
! yields Python methods (on the class Course):
!
! def form_is_taught_by(self, aProfessor):
!
! def drop_is_taught_by(self, aProfessor):
!
! def is_taught_by(self):
!
! def __is_taught_by(self):
!
! Multivalued Relationships
! - for a multivalued relationship such as:
!
! relationship set<X> Y inverse Z;
!
! we expand first to the IDL attribute and operations:
!
! readonly attribute set<X> Y;
!
! void form_Y(in X target) raises(IntegrityError);
!
! void drop_Y(in X target) raises(IntegrityError);
!
! void add_Y(in X target) raises(IntegrityError);
!
! void remove_Y(in X target) raises(IntegrityError);
!
! which results in the following Python methods:
!
! def Y(self):
!
! def form_Y(self, target):
!
! def drop_Y(self, target):
!
! def __add_Y(self, target):
!
! def __remove_Y(self, target):
!
! For example:
!
! interface Professor
! {
! ...
! relationship Set<Course> teaches
! inverse Course::is_taught_by;
! ...
! }
!
! Expand into the following IDL and attributes and operations:
!
! readonly attribute set<Course> teaches;
!
! void form_teaches(in Course aCourse) raises(IntegrityError);
!
! void drop_teaches(in Course aCourse) raises(IntegrityError);
!
! void add_teaches(in Course aCourse) raises(IntegrityError);
!
! void remove_teaches(in Course aCourse) raises(IntegrityError);
!
! which results in the following Python methods:
!
! def teaches(self):
!
! def form_teaches(self, aCourse):
!
! def drop_teaches(self, aCourse):
!
! def __add_teaches(self, aCourse):
!
! def __remove_teaches(self, aCourse):
!
! Collections
! - ch. 2 introduced several new kinds of collections that
! extend the IDL sequence
! - the following shows the Python interfaces/classes that this
! binding defines for each of the collection interfaces
\ No newline at end of file