E(ID:1477/e::001)C++ persistent dialect with data typesfor Exodus An extension of C++ with database types and persistent objects. 1989 Used in the Exodus database system. Featured iterators and generators Structures: Related languages
References: in Proceedings on the 1986 international workshop on Object-oriented database systems September 1986 view details in Proceedings of the 1987 ACM SIGMOD international conference on Management of Data ACM SIGMOD Record , 16(3) December 1987 view details in Software — Practice and Experience 19(12) December 1989 view details in Proceedings of the Third International Workshop on Persistent Object Systems January 1989 view details describes the main features of E and shows through examples how E addresses many of the problems that arise in building persistent systems. Extract: Motivation 1. Motivation In the mid-1980’s, several database research groups, responding to the needs of a variety of emerging applications, began to explore extensible database systems. Although different groups have different notions of what extensible means, a common desire is to support a high degree of flexibility for customizing the database system to the user's application. Such flexibility is mostly lacking in today’s commercial systems, and attempts to provide it through added software layers experienced severe performance penalties. These experiences prompted researchers to explore system architectures which could be extended easily and without loss of performance. For example, in an extensible DBMS, it should be easy to augment the collection of base types with new user-defined types. The EXODUS project at the University of Wisconsin has been exploring a toolkit approach to extensibility. The software tools simplify the construction of customized database systems as well as the extension of these systems once they have been built. The first component of the EXODUS toolkit is the EXODUS Storage Manager. It provides basic support for objects, files, and transactions. Next is the E programming language and its compiler. This paper describes the E language design; various approaches to the implementation of E are described in Richardson and Carey, Schuh et al. and Shekita and Zwilling. The third major EXODUS component is the Optimizer Generator, which allows a database implementor (DBI) to produce a customized query optimizer from a set of rules describing a given query algebra. E was originally intended as the language in which to write database system code, that is, abstract data types (eg., time), access methods (eg., grid files), and operator methods (eg., hash join) were all to be written in E. E was also intended as a target language for schema and query compilation, with user-defined schemas being translated into E types and user queries into E procedures. The difficulty in building a DBMS in a conventional systems programming language (eg., C) derives from several factors. First, the DBI must write code whose primary task is to manipulate shared data on secondary storage. A significant portion of the total system code is therefore devoted to interacting with the storage layer, eg., calling the buffer manager to read a record. Second, the DBI must write code for operators and access methods without knowing a priori the data types on which they might operate. For example, the DBI cannot know that some user will eventually want to build an index, keyed on area, over a set of polygons. Finally, the DBI must build a query processor that converts queries posed by end users into a form that the system can execute. This translation is greatly simplified if the basic operators can be written in a composable manner. These and other influences led to the design of the E language. While the original goals are still clearly evident, E has evolved into a general purpose language for coding persistent applications. E is an extension of C++ providing generator classes, iterators and persistent objects. C++ provided a good starting point with its class-based data abstraction features and its expanding popularity as a systems programming language. Parameterized types in the form of generator (or generic) classes were added for their utility both in defining database container types, such as sets and indices, as well as in expressing generic operators, such as select and join. Iterators were added as a useful programming construct in general, and as a mechanism for structuring database queries in particular. Both generators and iterators were inspired by CLU. Persistence - the ability of a language object to survive from one program run to the next - was added because it is an essential attribute of database objects. In addition, by describing the database or object base in terms of persistent variables, one may then manipulate it directly using expressions within the E language. Two factors influenced the way in which E’s extensions were added to C++. The first was the desire to maintain upward compatibility, that is, that E should be a strict superset of C++. Originally, we were forced to make a small compromise in order to support generator classes: in E, nested class definitions follow nested scope rules, while nested class definitions were exported to the global scope in versions 1.2 and 2.0 of C++. Now that C++ also supports nesting of class scopes, this is no longer a problem. The second important factor concerned efficiency. We desired that the C++ subset of E be compilable into code no less efficient than that produced by a C++ compiler. This primarily influenced the way in which we added persistence to the language: instead of allowing persistence to be a property of any object, we allow persistence only for objects whose type is declared to be a database (db) type. The design and implementation of E represent several contributions to the field of persistent programming languages. E and Avalon/C++, designed at approximately the same time, were the first to extend C++ with persistence. In Avalon/C++, persistence is based on inheritance from the class recoverable, and access to persistent objects must be within the context of a special pinning block. Persistence in E is based on the persistent storage class, and the 1/0 required to access a persistent object is transparent. The storage class approach has since appeared in at least two more recent language designs, Persistent Modula-3 and ObjectStore. E was also the first extension to add generic classes to C++; its design and implementation predated the C++ template design. In addition, E remains the only C++ extension to provide a general-purpose iterator construct. in Proceedings of the Third International Workshop on Persistent Object Systems January 1989 view details Observed advantages of using a persistent programming language for database system implementation include ease of implementation of specialpurpose persistent objects used by the DBMS such as catalogs, data indexes, rule indexes, and nested relational structures. Other advantages of using E (a persistent version of C++) that are independent of the persistence issue are the usefulness of objectoriented programming in developing large software systems, and the utility of the Collection abstraction in E. Observed disadvantages include (1) the inability to map the type system of the DBMS to the type system of the underlying programming language while still retaining good performance for ad-hoc queries, and (2) software engineering difficulties due to the distinction in E between database types and main-memory types. DOI in SIGPLAN Notices 26(11) November 1991 view details in IEEE Transactions on Computers July 19, 1991 view details 1. MOTIVATION In the mid-1980’s, several database research groups, responding to the needs of a variety of emerging applications, began to explore "extensible database systems". Although different groups have different notions of what "extensible" means, a common desire is to support a high degree of flexibility for customizing the database system to the user's application. Such flexibility is mostly lacking in today’s commercial systems, and attempts to provide it through added software layers experienced severe performance penalties. These experiences prompted researchers to explore system architectures which could be extended easily and without loss of performance. For example, in an extensible DBMS, it should be easy to augment the collection of "base" types with new user-defined types. The EXODUS project at the University of Wisconsin has been exploring a toolkit approach to extensibility. The software tools simplify the construction of customized database systems as well as the extension of these systems once they have been built. The first component of the EXODUS toolkit is the EXODUS Storage Manager. It provides basic support for objects, files, and transactions. Next is the E programming language and its compiler. This paper describes the E language design; various approaches to the implementation of E are described in Richardson and Carey, Schuh et al. and Shekita and Zwilling. The third major EXODUS component is the Optimizer Generator, which allows a database implementor (DBI) to produce a customized query optimizer from a set of rules describing a given query algebra. E was originally intended as the language in which to write database system code, that is, abstract data types (eg., time), access methods (eg., grid files), and operator methods (eg., hash join) were all to be written in E. E was also intended as a target language for schema and query compilation, with user-defined schemas being translated into E types and user queries into E procedures. The difficulty in building a DBMS in a conventional systems programming language (eg., C) derives from several factors. First, the DBI must write code whose primary task is to manipulate shared data on secondary storage. A significant portion of the total system code is therefore devoted to interacting with the storage layer, eg., calling the buffer manager to read a record. Second, the DBI must write code for operators and access methods without knowing a priori the data types on which they might operate. For example, the DBI cannot know that some user will eventually want to build an index, keyed on area, over a set of polygons. Finally, the DBI must build a query processor that converts queries posed by end users into a form that the system can execute. This translation is greatly simplified if the basic operators can be written in a composable manner. These and other influences led to the design of the E language. While the original goals are still clearly evident, E has evolved into a general purpose language for coding persistent applications. E is an extension of C++ [56, 18] providing generator classes, iterators and persistent objects. C++ provided a good starting point with its class-based data abstraction features and its expanding popularity as a systems programming language. Parameterized types in the form of generator (or generic) classes were added for their utility both in defining database container types, such as sets and indices, as well as in expressing generic operators, such as select and join. Iterators were added as a useful programming construct in general, and as a mechanism for structuring database queries in particular. Both generators and iterators were inspired by CLU. Persistence - the ability of a language object to survive from one program run to the next - was added because it is an essential attribute of database objects. In addition, by describing the database or object base in terms of persistent variables, one may then manipulate it directly using expressions within the E language. Two factors influenced the way in which E’s extensions were added to C++. The first was the desire to maintain upward compatibility, that is, that E should be a strict superset of C++. Originally, we were forced to make a small compromise in order to support generator classes: in E, nested class definitions follow nested scope rules, while nested class definitions were exported to the global scope in versions 1.2 and 2.0 of C++. Now that C++ also supports nesting of class scopes, this is no longer a problem. The second important factor concerned efficiency. We desired that the C++ subset of E be compilable into code no less efficient than that produced by a C++ compiler. This primarily influenced the way in which we added persistence to the language: instead of allowing persistence to be a property of any object, we allow persistence only for objects whose type is declared to be a database (db) type. Section 5 explains this point more fully. The design and implementation of E represent several contributions to the field of persistent programming languages. E and Avalon/C++, designed at approximately the same time, were the first to extend C++ with persistence. ln Avalon/C++, persistence is based on inheritance from the class recoverable, and access to persistent objects must be within the context of a special pinning block. Persistence in E is based on the persistent storage class, and the 1/0 required to access a persistent object is transparent. The storage class approach has since appeared in at least two more recent language designs, Persistent Modula-3 and ObjectStore. E was also the first extension to add generic classes to C++; its design and implementation predated the C++ template design. In addition, E remains the only C++ extension to provide a general-purpose iterator construct. in TOPLAS 15(3) July 1993 view details in Readings in database systems (2nd ed.) July 1994 view details in Journal of Object Oriented Programming, July 1995 view details Resources
|