Persistence predicates - Revision history

Conaclos: remove 'is' keyword

2013-05-20T15:13:32Z

remove 'is' keyword

← Older revision		Revision as of 15:13, 20 May 2013
Line 73:		Line 73:
	feature {NONE} -- Initialization		feature {NONE} -- Initialization

	make is		make
	-- Initialize `Current' with a new gadget.		-- Initialize `Current' with a new gadget.
	do		do
Line 81:		Line 81:
	end		end

	make_from_db (a_gadget_id: INTEGER; ...) is		make_from_db (a_gadget_id: INTEGER; ...)
	-- Initialize `Current' using `a_gadget_id' to create `gadget' from database.		-- Initialize `Current' using `a_gadget_id' to create `gadget' from database.
	do		do
Line 88:		Line 88:
	end		end

	initialize_attributes is		initialize_attributes
	-- Initialize `gadget' and ...		-- Initialize `gadget' and ...
	do		do
Line 95:		Line 95:
	end		end

	recreate_attributes (a_gadget_id: INTEGER; ...) is		recreate_attributes (a_gadget_id: INTEGER; ...)
	-- Recreate certain attributes.		-- Recreate certain attributes.
	do		do
Line 136:		Line 136:
	feature {NONE} -- Initialization		feature {NONE} -- Initialization

	make is		make
	-- Initialize `Current' with a new gadget.		-- Initialize `Current' with a new gadget.
	do		do
Line 143:		Line 143:
	end		end

	restore_gadgets (a_id, a_other_id: INTEGER; ...is		restore_gadgets (a_id, a_other_id: INTEGER; ...)
	-- Restore `gadget' and `gadget_from_a' from database.		-- Restore `gadget' and `gadget_from_a' from database.
	do		do

Colin-adams: Spelling correction

2007-10-04T07:58:44Z

Spelling correction

← Older revision		Revision as of 07:58, 4 October 2007
Line 156:		Line 156:
	attribute		attribute
	restore		restore
	~~presistence_predicate~~: False		persistance_predicate: False
	end		end

Colin-adams: Completed examples

2007-10-04T07:56:25Z

Completed examples

@@ Line 1: / Line 1: @@
 [[Category:Persistence]]
 {{Research}}
 ==Introduction==
@@ Line 64: / Line 63: @@
 <e>
-  gadget: GADGET_FROM_DATABASE
+class A
     -- Gadget retrieved from DB via its `id' attribute
    attribute
    restore
     persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
                                                                     --  with `True' being the default
     body: agent create_gadget_from_identifier (attribute.id)
 </e>
 Here the ECMA <e>attribute</e> keyword is reused to denote the instance of `gadget'. This is only available within the attribute restore clause, not in a restoration routine.
 ==Redefinition==

Colin-adams: Added missing agent keyword

2007-10-04T06:58:10Z

Added missing agent keyword

← Older revision		Revision as of 06:58, 4 October 2007
Line 71:		Line 71:
	persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,		persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
	-- with `True' being the default		-- with `True' being the default
	body: create_gadget_from_identifier (attribute.id)		body: agent create_gadget_from_identifier (attribute.id)
	</e>		</e>

Colin-adams: Restore keyword added. persistence keyword removed.

2007-09-28T07:08:32Z

Restore keyword added. persistence keyword removed.

← Older revision		Revision as of 07:08, 28 September 2007
Line 10:		Line 10:
	Another is that too much data may be stored, resulting in large files (or database occupancy, or whatever) and slow reload times. Some data, such as internal caches, are probably best not serialized at all. For other data, it may be better just to store a shorthand identifier to enable the data to be rebuilt (maybe on demand) at retrieval time.		Another is that too much data may be stored, resulting in large files (or database occupancy, or whatever) and slow reload times. Some data, such as internal caches, are probably best not serialized at all. For other data, it may be better just to store a shorthand identifier to enable the data to be rebuilt (maybe on demand) at retrieval time.

	This article explores ways to address the second problem.		This article explores ways to address the second problem. The first problem is best tackled by only using <e>STORABLE</e>s as a medium-term caching mechanism.

	==Transient data==		==Transient data==
Line 29:		Line 29:
	If a persistence predicate returns <e>False</e>, it may be that the programmer does not need this data at all (such as the case of an internal cache). But in some cases the programmer will want the data to be recreated at restoration time (this may be necessary to restore the class invariant), rather than retrieved from the persistence mechanism.		If a persistence predicate returns <e>False</e>, it may be that the programmer does not need this data at all (such as the case of an internal cache). But in some cases the programmer will want the data to be recreated at restoration time (this may be necessary to restore the class invariant), rather than retrieved from the persistence mechanism.

	Take an example of a class which has an attribute named <e>`gadget'</e> of type <e>GADGET_FROM_DATABASE</e> having an attribute named <e>`id'</e> of type <e>INTEGER</e>. The class invariant requires that<e>`gadget'</e> is not <e>Void</e>, but the size required to store <e>`gadget'</e> is very large. The class also has a secret routine <e>`~~gadget_from_identifier~~ (a_id: INTEGER)~~: GADGET_FROM_DATABASE'~~</e> which can be used to create a <e>GADGET_FROM_DATABASE</e> given its <e>`id'</e> value. In such a case, rather than store <e>`gadget'</e> it is probably better to just store the <e>`id'</e> value, and then call <e>`~~gadget_from_identifier~~'</e> at retrieval time.		Take an example of a class which has an attribute named <e>`gadget'</e> of type <e>GADGET_FROM_DATABASE</e> having an attribute named <e>`id'</e> of type <e>INTEGER</e>. The class invariant requires that<e>`gadget'</e> is not <e>Void</e>, but the size required to store <e>`gadget'</e> is very large. The class also has a secret routine <e>`create_gadget_from_identifier (a_id: INTEGER)</e> which can be used to create a <e>GADGET_FROM_DATABASE</e> given its <e>`id'</e> value. In such a case, rather than store <e>`gadget'</e> it is probably better to just store the <e>`id'</e> value, and then call <e>`create_gadget_from_identifier'</e> at retrieval time.

	A restoration routine is a ~~routine of type~~ <e>~~FUNCTION [ANY, TUPLE, {?\|!}<attribute_type>]~~</e> ~~associated with an attribute of type <attribute_type> which is called at retrieval time to restore the attribute~~.		A restoration routine is similar to a creation procedure, in as much as it cannot reply on the class invariant holding. It can rely on attributes for which the persistence predicate evaluates to <e>True </e> as having been restored, though.

	==Syntax==		==Syntax==

	~~Very hazy thoughts here. I did think about using indexing terms, but I'm not sure if they are appropriate~~.		One new keyword <e>restore</e> will be required. This can occur in several places:

	~~Maybe~~ one ~~new~~ keyword <e>~~persistence~~</e> ~~will be required~~. ~~Perhaps~~ after the ~~keyword~~ <e>~~persistence~~</e> ~~we will see something looking like indexing terms:~~		<ul>
			<li>After the <e>create</e> clause in the class prolog. What follows is a list of restoration routines, just like the list of creation procedures. Typically this will occur in the form:
			<e>
			restore {STORABLE}
			recreate_attributes
			</e>
			</li>
			<li>After the <e>attribute</e> keyword and optional body. What follows is:

			<p>1. The tag <e>persistence_predicate:</e> followed by one of:</p>

			<p>a) <e>True</e> meaning always persist.</p>
			<p>b) <e>False</e> meaning never persist.</p>
			<p>c) The keyword <e>agent</e> followed by a declaration of a <e>PREDICATE</e>.</p>

			<p>2. An optional body (introduced by the tag <e>body:</e>) like the attribute body, and this is code that is executed only if the attribute was not persisted. These routines run after all persisted attributes have been restored, but before the restoration procedure is run. It is only used for initialization of attributes that do not depend
			upon other restoration attribute bodies having been run.
			</p>
			</li>
			<li>
			Within a restoration routine as an instruction. Here it is used analagously to a <e>create</e> instruction, to run one of the named restoration routines specified in the class of one of the attributes that was not persisted.
			</li>
			</ul>

	===Example===		===Example===
Line 46:		Line 68:
	attribute		attribute
	...		...
	~~persistence~~		restore
	persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,		persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
	-- with `True' being the default		-- with `True' being the default
	~~restoration_routine~~: ~~agent gadget_from_identifier~~ (attribute.id) ~~-- Default is not to restore~~		body: create_gadget_from_identifier (attribute.id)
	</e>		</e>

	Here the ECMA <e>attribute</e> keyword is reused to denote the instance of `gadget'.		Here the ECMA <e>attribute</e> keyword is reused to denote the instance of `gadget'. This is only available within the attribute restore clause, not in a restoration routine.

	==Redefinition==		==Redefinition==
Line 64:		Line 86:
	==Class correctness conditions==		==Class correctness conditions==

	The possibility of the persistance_predicate evaluating to (or statically specified as) <e>False</e> on an attribute that is required to be non-Void (or non-default for an expanded attribute) implies that ~~the~~ restoration ~~routine~~ must be ~~specified in such cases. The use of an attached type as the return value of~~ the restoration routine ~~will be necessary to ensure class correctness in the case of invariant clauses which specify a non-Void attribute~~.		The possibility of the persistance_predicate evaluating to (or statically specified as) <e>False</e> on an attribute that is required to be non-Void (or non-default for an expanded attribute) implies that either inline restoration code must be supplied, or the restoration routine has an appropriate postcondition clause.

Colin-adams at 09:15, 27 September 2007

2007-09-27T09:15:42Z

New page

[[Category:Persistence]]
{{UnderConstruction}}
{{Research}}
==Introduction==

Using <e>STORABLE</e>s in an application has at least two significant disadvantages.

One is that using them for long-term persistence is vulnerable to changes in the class.

Another is that too much data may be stored, resulting in large files (or database occupancy, or whatever) and slow reload times. Some data, such as internal caches, are probably best not serialized at all. For other data, it may be better just to store a shorthand identifier to enable the data to be rebuilt (maybe on demand) at retrieval time.

This article explores ways to address the second problem.

==Transient data==

Java tackles this problem with the keyword <java>transient</java>. An attribute so marked is not stored at serialization time. When the object is retrieved the attribute will be void.

This seems rather limited to me. It can't be used if the class invariant constrains the attribute to be non-void. And I don't think there is a way for a descendant class to override this behaviour (it's a long time since I've written any Java, so I could be very wrong here).

My thinking is that there should be a way to specify whether or not a particular attribute should be stored on any given occaision, and a way to specify what to do at retrieval time.

===Persistence predicates===

A persistence predicate is a routine of type <e>PREDICATE [ANY, TUPLE [!<attribute_type>]]</e> associated with an attribute of type <attribute_type>.
At storage time, the predicate will be called with the instance of the attribute as its argument (if the attribute is non-Void). If it returns <e>True</e> then the attribute is stored. If it returns <e>False</e> then the attribute is not stored, but it may be re-created at retrieval time.

===Restoration routines===

If a persistence predicate returns <e>False</e>, it may be that the programmer does not need this data at all (such as the case of an internal cache). But in some cases the programmer will want the data to be recreated at restoration time (this may be necessary to restore the class invariant), rather than retrieved from the persistence mechanism.

Take an example of a class which has an attribute named <e>`gadget'</e> of type <e>GADGET_FROM_DATABASE</e> having an attribute named <e>`id'</e> of type <e>INTEGER</e>. The class invariant requires that<e>`gadget'</e> is not <e>Void</e>, but the size required to store <e>`gadget'</e> is very large. The class also has a secret routine <e>`gadget_from_identifier (a_id: INTEGER): GADGET_FROM_DATABASE'</e> which can be used to create a <e>GADGET_FROM_DATABASE</e> given its <e>`id'</e> value. In such a case, rather than store <e>`gadget'</e> it is probably better to just store the <e>`id'</e> value, and then call <e>`gadget_from_identifier'</e> at retrieval time.

A restoration routine is a routine of type <e>FUNCTION [ANY, TUPLE, {?|!}<attribute_type>]</e> associated with an attribute of type <attribute_type> which is called at retrieval time to restore the attribute.

==Syntax==

Very hazy thoughts here. I did think about using indexing terms, but I'm not sure if they are appropriate.

Maybe one new keyword <e>persistence</e> will be required. Perhaps after the keyword <e>persistence</e> we will see something looking like indexing terms:

===Example===

<e>
gadget: GADGET_FROM_DATABASE
-- Gadget retrieved from DB via its `id' attribute
attribute
...
persistence
persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
-- with `True' being the default
restoration_routine: agent gadget_from_identifier (attribute.id) -- Default is not to restore
</e>

Here the ECMA <e>attribute</e> keyword is reused to denote the instance of `gadget'.

==Redefinition==

The open/closed principle is honoured (I think). The author of the class can determine that an attribute must always be stored (this is the default, and is the current situation), or that it is never stored (for a pure cache attribute), or provide flexibility by specifying an agent.

The agent's routine could be deferred, frozen (yuk!) or just a normal routine, in which case descendant classes can redefine it.

The actual instance data that is passed to the persistance_predicate and the restoration_routine could be specified via an agent, which allows for further flexibility. For restoration, it might even involve an <e>EV_DIALOG</e> (heaven forfend)!

==Class correctness conditions==

The possibility of the persistance_predicate evaluating to (or statically specified as) <e>False</e> on an attribute that is required to be non-Void (or non-default for an expanded attribute) implies that the restoration routine must be specified in such cases. The use of an attached type as the return value of the restoration routine will be necessary to ensure class correctness in the case of invariant clauses which specify a non-Void attribute.