Persistence predicates - Revision history

Conaclos: remove 'is' keyword

2013-05-20T15:13:32Z

remove 'is' keyword

Colin-adams: Spelling correction

2007-10-04T07:58:44Z

Spelling correction

Colin-adams: Completed examples

2007-10-04T07:56:25Z

Completed examples

Colin-adams: Added missing agent keyword

2007-10-04T06:58:10Z

Added missing agent keyword

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

2007-09-28T07:08:32Z

Restore keyword added. persistence keyword removed.

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.

@@ Line 73: / Line 73: @@
 feature {NONE} -- Initialization
-  make is
+  make
     -- Initialize `Current' with a new gadget.
    do
@@ Line 81: / Line 81: @@
    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.
    do
@@ Line 88: / Line 88: @@
    end
-  initialize_attributes is
+  initialize_attributes
     -- Initialize `gadget' and ...
    do
@@ Line 95: / Line 95: @@
    end
-  recreate_attributes (a_gadget_id: INTEGER; ...) is
+  recreate_attributes (a_gadget_id: INTEGER; ...)
     -- Recreate certain attributes.
    do
@@ Line 136: / Line 136: @@
 feature {NONE} -- Initialization
-  make is
+  make
     -- Initialize `Current' with a new gadget.
    do
@@ Line 143: / Line 143: @@
    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.
    do

@@ Line 156: / Line 156: @@
    attribute
    restore
-    presistence_predicate: False
+    persistance_predicate: False
    end

@@ Line 71: / Line 71: @@
     persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
                                                                     --  with `True' being the default
-    body: create_gadget_from_identifier (attribute.id)
+    body: agent create_gadget_from_identifier (attribute.id)
 </e>

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

@@ 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.
-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==
@@ 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.
-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==
-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>
 ===Example===
@@ Line 46: / Line 68: @@
    attribute
     ...
-   persistence
+   restore
     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
+    body: create_gadget_from_identifier (attribute.id)
 </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==
@@ Line 64: / Line 86: @@
 ==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.