Difference between revisions of "Persistence unified"

(→‎Code samples)
(→‎Design principles)
 
(33 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
[[Category:Persistence]]
 
==Unified persistence for Eiffel==
 
==Unified persistence for Eiffel==
−
This project is about developing a single, integrated and simple persistence framework for Eiffel.
+
(Temporary name: PERSIST.)
  
−
*Single because nothing else should be needed to access any kind of persistence services.
+
The PERSIST project is about developing a single, integrated and simple persistence framework for Eiffel:
−
*Integrated because aims at integrating both the already existing technologies  and frameworks, as far as they deliver the intended benefits, and possibly new ones.
+
−
*Simple because it should be very easy to use, removing all the unnecessary complexity.
+
  
−
==A tentative manifesto==
+
*'''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.
−
The first proposed task is to agree upon a sort of ‘manifesto’ of desirable features for the framework.  
+
*'''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.
  
−
Here is a first proposal:
+
Community input is expressly sought to help PERSIST achieve these goals.
  
−
===Three abstractions===
+
==Existing persistence mechanisms==
−
The framework should provide just three abstractions to the developer: PERSISTENCE_MEDIUM, PERSISTENCE_FORMAT and PERSISTENCE_MANAGER.
+
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 [[:Category:Persistence|general persistence page]], and if you are familiar with a project not referenced there please add it.
  
−
Possible specializations of these abstractions could be:  
+
==Design principles==
 +
The following goals, detailed next, appear essential:
  
−
* FILE_MEDIUM, NETWORK_MEDIUM, RELATIONAL_DB_MEDIUM, CUSTOM_MEDIUM, ...
+
# Design orthogonality
 +
# Persistence uniformity
 +
# Encapsulation and extension
 +
# Pure Eiffel
 +
# Object and class versioning
 +
# Custom persistence
 +
# Newbie-proof
  
−
* BINARY_FORMAT, STRING_FORMAT, XML_FORMAT, DADL_FORMAT, CUSTOM_FORMAT, ...
 
  
−
* SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ...
+
===Design orthogonality===
 +
It should be possible to add persistence mechanisms to an application without affecting the other aspects of its design. For example, developers should not need to add persistence-related attributes to application classes, or require them to inherit from specific persistence classes.
  
−
===Persistence independence===
+
===Persistence uniformity===
−
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.
+
There are many kinds of persistence media, 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.
  
−
*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. This can be achieved using the XXX_MEDIUM class hierarchy.
+
It should be possible to add new kinds of persistence medium. For a possible approach see XXX_FORMAT classes below.
−
*The different formats should be properly incapsulated. This can be achieved using the XXX_FORMAT class hierarchy.
+
  
 
===Pure Eiffel===
 
===Pure Eiffel===
−
No external calls to C macros, just plain Eiffel should be used to implement the framework
+
PERSIST should entirely be implementable in Eiffel: no C routines or macros.
−
==Code samples==
+
 
−
Here is a link to the [[persistence code samples page]] where you can have have a look at some code.  
+
(Handles to existing C-based mechanisms, e.g. a relational DBMS, may as usual require short C routines.)
 +
 
 +
===Object and class versioning===
 +
PERSIST should make it possible to retrieve objects even if the class description has changed. Conversions between objects of different versions should be safe. All the different class versions should be stored in a central repository, together with the appropriate conversion routines.
 +
=== Custom persistence ===
 +
Developers should be given the choice of how much control they exert over the storage mechanism. In particular, they should be able to choose which attribute to store. Storing all the attributes of an object, albeit a reasonable default, can be either inefficient or inflexible, or both.
 +
 
 +
===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]].  
  
−
TODO: provide a link to the sources
+
===Name search===
 +
PERSIST is a placeholder name. Suggestions are welcome.
  
−
==Additional tasks==
+
==Contacts==
−
===Which name?===
+
*Marco Piccioni
−
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.
+
*Bertrand Meyer

Latest revision as of 06:09, 23 April 2009

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:

  1. Design orthogonality
  2. Persistence uniformity
  3. Encapsulation and extension
  4. Pure Eiffel
  5. Object and class versioning
  6. Custom persistence
  7. Newbie-proof


Design orthogonality

It should be possible to add persistence mechanisms to an application without affecting the other aspects of its design. For example, developers should not need to add persistence-related attributes to application classes, or require them to inherit from specific persistence classes.

Persistence uniformity

There are many kinds of persistence media, 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.

Encapsulation and Extension

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 and class versioning

PERSIST should make it possible to retrieve objects even if the class description has changed. Conversions between objects of different versions should be safe. All the different class versions should be stored in a central repository, together with the appropriate conversion routines.

Custom persistence

Developers should be given the choice of how much control they exert over the storage mechanism. In particular, they should be able to choose which attribute to store. Storing all the attributes of an object, albeit a reasonable default, can be either inefficient or inflexible, or both.

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
Retrieved from "https://dev.eiffel.com/index.php?title=Persistence_unified&oldid=12513"