The term "persistence" covers all mechanisms that allow Eiffel objects to exist beyond the scope of a particular system execution.
A number of persistence solutions have been developed. The aim of this Category page is twofold:
- To identify, document and catalog existing solutions.
- To provide the basis for a single, unified mechanism covering all future persistence needs (the Unified Persistence Project.
- 1 Existing persistence mechanisms
- 2 Unified Persistence Project
- 3 OOSC specification
- 4 Unified persistence for Eiffel
- 5 A tentative manifesto
- 6 Diagrams and code samples
- 7 Open discussion
- 8 Additional tasks
Existing persistence mechanisms
(If you know of an approach not covered in the list, please add a short mention here and, if appropriate, a link to a more detailed description, e.g. a new page in the Persistence category. Only approaches that can work with EiffelStudio are relevant.)
- STORABLE mechanism: general facility for storing object structures (all objects reachable from a given object, following the "persistence closure" principle). There are several variants of this mechanism:
- Class STORABLE in the original EiffelBase, since widely used.
- EiffelStore library: Object-relational interface.
- EiffelNet library: uses STORABLE to exchange object structures over a network
Unified Persistence Project
An ongoing project to provide a solution combining the best of all previous approaches.
A number of the developments listed here rely in whole or in part on the specification given in chapter 30 of Object-Oriented Software Construction.
Unified persistence for Eiffel
This project is about developing a single, integrated and simple persistence framework for Eiffel.
- Single because nothing else should be needed to access any kind of persistence services (e.g. serialization, RDBMS, OODBMS).
- Integrated because aims at integrating both the already existing technologies and frameworks and possibly new ones, as far as they all deliver the intended benefits.
- Simple because by removing all the unnecessary complexity it should be very easy and straightforward to use even for an Eiffel newcomer programmer.
A tentative manifesto
The first proposed task is to agree upon a sort of ‘manifesto’ of desirable features for the framework.
Here is a first proposal:
- Essential abstractions
- Independence from persistence code
- Uniform access
- Encapsulation and extension
- Pure Eiffel
You can find some details in the following paragraphs.
The framework should provide just three abstractions to the developer: PERSISTENCE_MEDIUM, PERSISTENCE_FORMAT and PERSISTENCE_MANAGER.
Possible specializations of these abstractions could be:
- 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, ...
Independence from persistence code
Classes which objects have to be persisted should not be polluted with persistence code, for example by adding specific persistence-related attributes or by inhering from some other class that provides persistence services.
The access to the persistence services should be as uniform as possible. This can be achieved using the XXX_MANAGER class hierarchy that handles access to specific kinds of persistence stores.
Encapsulation and extension
The different media should be properly incapsulated and the same time there should be place for extensions. This can be achieved using the XXX_MEDIUM class hierarchy.
The different formats should be properly incapsulated and the same time there should be place for extensions. This can be achieved using the XXX_FORMAT class hierarchy.
No external calls to C macros, just plain Eiffel should be used to implement the framework
Ideally the programmer should only create the desired manager object and invoke the features to store or retrieve an object passing the object itself as an argument.
Diagrams and code samples
Here is a link to the persistence code samples page where you can have a look at some code and a class diagram.
For an open discussion on the design choices please have a look at the persistence framework design discussion.
Find an appropriate name for the framework is, of course, absolutely fundamental. It seems fair that anyone interested could provide one or more names within a certain period of time. After that a poll may be created to determine the winner. A first proposal could be EIUNPE which stands for EIffel UNified PErsistence.