Persistence unified - Revision history

Marco Piccioni: /* Design principles */

2009-04-23T15:09:02Z

Design principles

← Older revision		Revision as of 15:09, 23 April 2009
Line 21:		Line 21:
	# Encapsulation and extension		# Encapsulation and extension
	# Pure Eiffel		# Pure Eiffel
	# Object versioning		# Object and class versioning
			# Custom persistence
	# Newbie-proof		# Newbie-proof

Marco Piccioni: /* Object versioning */

2009-04-23T15:08:16Z

Object versioning

← Older revision		Revision as of 15:08, 23 April 2009
Line 39:		Line 39:
	(Handles to existing C-based mechanisms, e.g. a relational DBMS, may as usual require short C routines.)		(Handles to existing C-based mechanisms, e.g. a relational DBMS, may as usual require short C routines.)

	===Object versioning===		===Object and class 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~~.		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===		===Newbie-proof===

Marco Piccioni: /* Design orthogonality */

2009-04-23T14:57:02Z

Design orthogonality

← Older revision		Revision as of 14:57, 23 April 2009
Line 26:		Line 26:

	===Design orthogonality===		===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, or require ~~application classes~~ to inherit from specific persistence classes.		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===		===Persistence uniformity===

Marco Piccioni: /* Object versioning */

2007-08-30T14:28:48Z

Object versioning

← Older revision		Revision as of 14:28, 30 August 2007
Line 39:		Line 39:
	(Handles to existing C-based mechanisms, e.g. a relational DBMS, may as usual require short C routines.)		(Handles to existing C-based mechanisms, e.g. a relational DBMS, may as usual require short C routines.)

	==Object versioning==		===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.		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.		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==		==Initial design==

Marco Piccioni: /* Extendibility */

2007-08-30T14:28:28Z

Extendibility

← Older revision		Revision as of 14:28, 30 August 2007
Line 31:		Line 31:
	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.		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.

	===~~Extendibility~~===		===Encapsulation and Extension===
	It should be possible to add new kinds of persistence medium. For a possible approach see XXX_FORMAT classes below.		It should be possible to add new kinds of persistence medium. For a possible approach see XXX_FORMAT classes below.

Marco Piccioni: /* Design orthogonality */

2007-08-30T14:27:40Z

Design orthogonality

← Older revision		Revision as of 14:27, 30 August 2007
Line 26:		Line 26:

	===Design orthogonality===		===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.		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, or require application classes to inherit from specific persistence classes.

	===Persistence uniformity===		===Persistence uniformity===

Marco Piccioni: /* Persistence uniformity */

2007-08-30T14:26:03Z

Persistence uniformity

← Older revision		Revision as of 14:26, 30 August 2007
Line 29:		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 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.

	===Extendibility===		===Extendibility===

Bertrand Meyer at 00:32, 27 August 2007

2007-08-27T00:32:47Z

← Older revision		Revision as of 00:32, 27 August 2007
Line 15:		Line 15:

	==Design principles==		==Design principles==
	The ~~first task is to agree on desirable features for PERSIST. Here is a first proposal~~:		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
	~~# Essential abstractions~~

	~~You can find some details in the following paragraphs.~~

	===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. (For a possible approach see XXX_FORMAT classes below.)		It should be possible to add new kinds of persistence medium. For a possible approach see XXX_FORMAT classes below.

	===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.

			(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===
	~~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~~.		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===
	~~It should~~ be possible to develop most persistence-aware applications based on knowledge of just three 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 ~~could be~~:		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.

	==~~Diagrams and code samples~~==		==Discussion==
	~~Here is a link~~ to the [[persistence ~~code samples~~]] ~~page where you can have a look at some code and a class diagram~~.		Feel free to participate in the [[persistence framework design discussion]].

	==~~Open discussion~~==		===Name search===
	~~For an open discussion on the design choices please have a look at the [[persistence framework design discussion]].~~		PERSIST is a placeholder name. Suggestions are welcome.
	~~==Additional tasks~~==
	~~===Which name?===~~
	~~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~~.

	==Contacts==		==Contacts==
	*Marco Piccioni		*Marco Piccioni
	*Bertrand Meyer		*Bertrand Meyer

Bertrand Meyer: /* Design orthogonality */

2007-08-27T00:11:18Z

Design orthogonality

← Older revision		Revision as of 00:11, 27 August 2007
Line 28:		Line 28:
	===Design orthogonality===		===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.		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===		===Persistence uniformity===

Bertrand Meyer at 00:11, 27 August 2007

2007-08-27T00:11:01Z

@@ Line 14: / Line 14: @@
 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.
-==A tentative manifesto==
+==Design principles==
 The first task is to agree on desirable features for PERSIST. Here is a first proposal:
-# Essential abstractions
+# Design orthogonality
-# Independence from persistence code
+# Persistence uniformity
 # Encapsulation and extension
 # Pure Eiffel
 # Newbie-proof
 You can find some details in the following paragraphs.
 ===Essential abstractions===
@@ Line 40: / Line 57: @@
 * BINARY_SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ...
 ==Diagrams and code samples==