This site's content was compiled from 1993 to 2006. Beyond that, Google is your friend.
Darren Hiebert
A recoverable STORABLE facility.
One of the problems using the storable facility of Eiffel is that if the attributes of the object change, the stored object becomes unrecoverable, even if the object was stored using independent_store.
Meyer, in section 31.3 of Object-Oriented Software Construction (OOSC), offers an object-oriented solution to the problem of schema evolution. However, this solution has never been previously implemented.
This package addresses that shortcoming. It decomposes an object into a meta-representation which can be safely recovered, even if the case of added or deleted attributes from an object. It is recommended to read the above referenced section of OOSC prior to using this library.
The class RECOVERABLE_STORABLE operates nearly identically to the current STORABLE class and would be used in its place. Recoverable-Storable also implements the mismatch correction facility described by Meyer.
Whenever an object stored using RECOVERABLE_STORABLE is being recovered, the library checks to see if every attribute of the object's generating class in the current system has a matching attribute in the meta-object read from the file. Two attributes are considered to match if they have the same name and same basic type (i.e. INTEGER, DOUBLE, REFERENCE, etc.). If an attribute in the current system is not found to have a match in the object being recovered, a mismatch is detected and if the generating class in the current system conforms to CORRECTABLE, correct_mismatch is called on that object after all matching attributes have been copied into the new object.
An attribute in the original object, but not in the current object, does not trigger a mismatch (per Meyer). An attribute with a matching name but different basic type is equivalent to a removal of the original attribute and the addition of a new attribute (per Meyer).
There is also a mechanism in place to permit changing the name of the generating class of an object stored with this library. In other words, if an object of class A is stored using this library, it can be recovered in a system where class A has been renamed as B. Class renaming is accomplished by creating a file containing the name translations and setting the environment variable RECOVERABLE_TRANSLATION to the path to the file. When the objects are recovered, any object generated by class A will now be assumed as generated by class B.
The general format of the translation file is quite similar to the class renaming facility of LACE. The general form looks like this:
rename
-- This is a comment
CLASS_A1 as CLASS_A2 -- This is another comment
CLASS_B1 as CLASS_B2
end
This primary use of this renaming mechanism is for database conversion programs which convert one database representation into another.