Difference between revisions of "Persistence unified"
(→Design orthogonality) |
|||
| Line 15: | Line 15: | ||
==Design principles== | ==Design principles== | ||
| − | The | + | The following goals, detailed next, appear essential: |
# Design orthogonality | # Design orthogonality | ||
| Line 21: | Line 21: | ||
# Encapsulation and extension | # Encapsulation and extension | ||
# Pure Eiffel | # Pure Eiffel | ||
| + | # Object versioning | ||
# Newbie-proof | # Newbie-proof | ||
| − | |||
| − | |||
===Design orthogonality=== | ===Design orthogonality=== | ||
| Line 30: | Line 29: | ||
===Persistence uniformity=== | ===Persistence uniformity=== | ||
| − | |||
There are many kinds of persistence medium, from plain files to relational databases, object-oriented databases and networks. Programmers using PERSIST should only have to take into account the properties of the persistence medium that they choose to consider. This means in particular that it must be possible to write a PERSIST application that will work with different persistence media. | There are many kinds of persistence medium, from plain files to relational databases, object-oriented databases and networks. Programmers using PERSIST should only have to take into account the properties of the persistence medium that they choose to consider. This means in particular that it must be possible to write a PERSIST application that will work with different persistence media. | ||
===Extendibility=== | ===Extendibility=== | ||
| − | It should be possible to add new kinds of persistence medium. | + | It should be possible to add new kinds of persistence medium. For a possible approach see XXX_FORMAT classes below. |
===Pure Eiffel=== | ===Pure Eiffel=== | ||
| − | + | PERSIST should entirely be implementable in Eiffel: no C routines or macros. | |
| + | |||
| + | (Handles to existing C-based mechanisms, e.g. a relational DBMS, may as usual require short C routines.) | ||
| + | |||
| + | ==Object versioning== | ||
| + | PERSIST should make it possible to retrieve objects even if the class description has changed. Conversions should be safe; developers should be given the choice of how much control they exert over them. | ||
===Newbie-proof=== | ===Newbie-proof=== | ||
| − | + | This is a direct application of the above requirement of simplicity: it should be possible for a novice programmer to store an object or an object structure using a straightforward single instruction, similar to what STORABLE permits today. | |
| + | |||
| + | |||
| + | ==Initial design== | ||
| + | What follows is a first attempt at isolating the critical abstractions and the architecture of PERSIST. | ||
===Essential abstractions=== | ===Essential abstractions=== | ||
| − | + | We have produced a first design intended to satisfy the above criteria. | |
| + | |||
| + | In this approach it will be possible to develop most persistence-aware applications based on knowledge of just three abstractions: | ||
*PERSISTENCE_MEDIUM, covering the kind of medium onto which objects are mapped; it should be possible to work with a very abstract view of such a medium, or, if desired, to take advantage of more specific properties. | *PERSISTENCE_MEDIUM, covering the kind of medium onto which objects are mapped; it should be possible to work with a very abstract view of such a medium, or, if desired, to take advantage of more specific properties. | ||
*PERSISTENCE_FORMAT, controlling the mapping between object properties and their outside representation. | *PERSISTENCE_FORMAT, controlling the mapping between object properties and their outside representation. | ||
*PERSISTENCE_MANAGER: control object to specify modalities of writing and reading, and find out how the operations actually occurred. | *PERSISTENCE_MANAGER: control object to specify modalities of writing and reading, and find out how the operations actually occurred. | ||
| − | Possible specializations of these abstractions | + | Possible specializations of these abstractions include: |
* FILE_MEDIUM, NETWORK_MEDIUM, RELATIONAL_DB_MEDIUM, CUSTOM_MEDIUM, ... | * FILE_MEDIUM, NETWORK_MEDIUM, RELATIONAL_DB_MEDIUM, CUSTOM_MEDIUM, ... | ||
| Line 56: | Line 65: | ||
* BINARY_SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ... | * BINARY_SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ... | ||
| + | ==Diagrams and high-level Eiffel descriptions== | ||
| + | A separate [[persistence code samples]] page provides a class diagram and the essentials of selected classes. | ||
| − | == | + | ==Discussion== |
| − | + | Feel free to participate in the [[persistence framework design discussion]]. | |
| − | == | + | ===Name search=== |
| − | + | PERSIST is a placeholder name. Suggestions are welcome. | |
| − | + | ||
| − | + | ||
| − | + | ||
==Contacts== | ==Contacts== | ||
*Marco Piccioni | *Marco Piccioni | ||
*Bertrand Meyer | *Bertrand Meyer | ||
Revision as of 16:32, 26 August 2007
Contents
Unified persistence for Eiffel
(Temporary name: PERSIST.)
The PERSIST project is about developing a single, integrated and simple persistence framework for Eiffel:
- Single: PERSIST should remove the need for any more specific solution such as serialization, object-relational interfaces, interfaces to object-oriented databases, all of which become functionalities of PERSIST.
- Integrated: PERSIST should integrate existing mechanisms and add new ones as needed, in a consistent framework.
- Simple: PERSIST should hide all unnecessary complexity from programmers; in Alan Kay's words, easy things should be easy and difficult things should possible.
Community input is expressly sought to help PERSIST achieve these goals.
Existing persistence mechanisms
Many people have devoted considerable efforts to persistence in Eiffel. It is important to take advantage of their insights and tools, and not to reinvent what has already been devised. Please make sure you are familiar with the list on the general persistence page, and if you are familiar with a project not referenced there please add it.
Design principles
The following goals, detailed next, appear essential:
- Design orthogonality
- Persistence uniformity
- Encapsulation and extension
- Pure Eiffel
- Object versioning
- Newbie-proof
Design orthogonality
It should be possible to add persistence mechanisms to an application without affecting the other aspects of its design. Developers should not, for example, need to add persistence-related attributes, or require application classes to inherit from specific persistence classes.
Persistence uniformity
There are many kinds of persistence medium, from plain files to relational databases, object-oriented databases and networks. Programmers using PERSIST should only have to take into account the properties of the persistence medium that they choose to consider. This means in particular that it must be possible to write a PERSIST application that will work with different persistence media.
Extendibility
It should be possible to add new kinds of persistence medium. For a possible approach see XXX_FORMAT classes below.
Pure Eiffel
PERSIST should entirely be implementable in Eiffel: no C routines or macros.
(Handles to existing C-based mechanisms, e.g. a relational DBMS, may as usual require short C routines.)
Object versioning
PERSIST should make it possible to retrieve objects even if the class description has changed. Conversions should be safe; developers should be given the choice of how much control they exert over them.
Newbie-proof
This is a direct application of the above requirement of simplicity: it should be possible for a novice programmer to store an object or an object structure using a straightforward single instruction, similar to what STORABLE permits today.
Initial design
What follows is a first attempt at isolating the critical abstractions and the architecture of PERSIST.
Essential abstractions
We have produced a first design intended to satisfy the above criteria.
In this approach it will be possible to develop most persistence-aware applications based on knowledge of just three abstractions:
- PERSISTENCE_MEDIUM, covering the kind of medium onto which objects are mapped; it should be possible to work with a very abstract view of such a medium, or, if desired, to take advantage of more specific properties.
- PERSISTENCE_FORMAT, controlling the mapping between object properties and their outside representation.
- PERSISTENCE_MANAGER: control object to specify modalities of writing and reading, and find out how the operations actually occurred.
Possible specializations of these abstractions include:
- FILE_MEDIUM, NETWORK_MEDIUM, RELATIONAL_DB_MEDIUM, CUSTOM_MEDIUM, ...
- BINARY_FORMAT, STRING_FORMAT, XML_FORMAT, DADL_FORMAT, CUSTOM_FORMAT, ...
- BINARY_SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ...
Diagrams and high-level Eiffel descriptions
A separate persistence code samples page provides a class diagram and the essentials of selected classes.
Discussion
Feel free to participate in the persistence framework design discussion.
Name search
PERSIST is a placeholder name. Suggestions are welcome.
Contacts
- Marco Piccioni
- Bertrand Meyer
