7/30/02 dbh0201 Recoverable Storable Facility 1 The Recoverable Storable Facility A Mismatch...
-
Upload
brandi-grimshaw -
Category
Documents
-
view
217 -
download
0
Transcript of 7/30/02 dbh0201 Recoverable Storable Facility 1 The Recoverable Storable Facility A Mismatch...
Recoverable Storable Facility
17/30/02 dbh0201
The Recoverable Storable Facility
A Mismatch Correction Mechanism for Handling Schema Evolution in an Eiffel System
by
Darren B. Hiebert
Recoverable Storable Facility
27/30/02 dbh0201
References
Section 31.3 of Object-Oriented Software Construction, 2nd Edition, by Bertrand Meyer (OOSC), contains a discussion of the problem of schema evolution in an object-oriented system, and loosely defines a proposed solution.
Recoverable Storable Facility
37/30/02 dbh0201
Problem
How do you recover an object from persistent storage when the generating class of the stored object has changed since it was stored (e.g. via STORABLE)?
If the object was stored using the facilities of the ISE (now Eiffel Software) class STORABLE, the system will exit with a retrieval exception. This discourages its use in any application where
preservation of data is important. Recoverable Storable is an implementation of the
solution proposed in OOSC, with minor variations.
Recoverable Storable Facility
47/30/02 dbh0201
Definitions
“Schema evolution occurs if at least one class used by a system that attempts to retrieve some objects (the retrieving system) differs from its counterpart in the system that stored these objects (the storing system).” [OOSC, p. 1041]
“Object retrieval mismatch, or just object mismatch for short, occurs when the retrieving system actually retrieves a particular object whose own generating class was different in the storing system.” [OOSC, p. 1041]
Recoverable Storable Facility
57/30/02 dbh0201
Solutions
Throw away pre-existing stored objects Simplest approach Upsets users
One-time, en-masse, conversion of stored objects (i.e. “database conversion”) Requires down-time of application Multiple conversions require careful sequencing
On-the-fly object conversion A more general solution than en-masse conversion,
allowing it to be used to implement en-masse conversion
Requires no down-time of application
Recoverable Storable Facility
67/30/02 dbh0201
On-the-fly Object Conversion
Consists of three phases: Detection
Retrieval subsystem detects object mismatches. Notification
Retrieval subsystem notifies retrieving system of object mismatch (appropriate correction is application-dependent).
Correction Retrieving system corrects object mismatch using
domain-specific knowledge.
Recoverable Storable Facility
77/30/02 dbh0201
Detection of Object Mismatch
Two Approaches: Nominal
Reads version number of generating class recorded in object.
Requires low-level run-time support. Structural
Detected by recording, for each object, “a class descriptor deduced from the actual structure of a class.” [OOSC p. 1043]
The class descriptor includes “the class name, the list of its attributes, each characterized by its name and its type” (strategy C3, per OOSC). [OOSC, p. 1043]
Recoverable Storable Facility
87/30/02 dbh0201
Notification of the Retrieving System
Proposed solution from OOSC: Class ANY contains a procedure correct_mismatch,
which is called on the retrieved object by the retrieval subsystem, and which is responsible for handling the mismatch.
Class ANY also contains a “once” function, mismatch_information, of type ANY to provide correct_mismatch with more information.
Recoverable Storable Facility
97/30/02 dbh0201
Correction of Object Mismatch
Proposed solution from OOSC: The procedure correct_mismatch from ANY has a default
implementation of raising an exception. A class which can undertake object mismatch correction redefines
correct_mismatch. Two mismatch scenarios must be considered:
Removal of attributeNo action required, since attribute is no longer referenced
Addition of new attributeRequires initialization of some kind
Other problems (e.g. change of attribute name or type) are reducible to a combination of the above two problems.
Recoverable Storable Facility
107/30/02 dbh0201
Addition of Attribute
The retrieval subsystem initializes new attributes to default values (as in object creation).
The modified generating class of the retrieved object may impose constraints upon the value of the new attribute (expressed as class invariants) and has sufficient knowledge to initialize it. The purpose of a creation routine is to establish the
class invariant of the newly created object. Likewise, the purpose of correct_mismatch is to re-
establish the class invariant of the retrieved object. The correct_mismatch procedure may also require
access to removed or original attributes in order to do its job.
Recoverable Storable Facility
117/30/02 dbh0201
Recoverable Storable
Decomposes objects in the supplied object tree into a meta-representation
Constructs a class descriptor by using the reflection facilities available in ISE Eiffel through its INTERNAL class
Uses STORABLE to store the meta-representation of the object tree
Provides capability to rename a class Handles the case where the name of the generating
class of a retrieved object has changed New extension to basic solution proposed in OOSC Name translation can be controlled programmatically
or via a text file referenced by an environment variable
Recoverable Storable Facility
127/30/02 dbh0201
Recoverable Storable (continued)
Since correct_mismatch is not included in the delivered ANY class, the proposed solution from OOSC would require a modification to ANY. To avoid modification of the delivered ANY class,
Recoverable Storable introduces, instead, the class CORRECTABLE, containing correct_mismatch and mismatch_information.
If an object mismatch is detected and its generating class in the retrieving system is a descendent of CORRECTABLE, then correct_mismatch is called.
CORRECTABLE and correct_mismatch are deferred, since a default implementation is unnecessary.
Recoverable Storable Facility
137/30/02 dbh0201
Recoverable Storable (continued)
The once function, mismatch_information, is of type HASH_TABLE [ANY, STRING] instead of ANY, returning a table of original attribute values hashed by attribute name. All of the original attributes of the retrieved object are
available to correct_mismatch.
Recoverable Storable Facility
147/30/02 dbh0201
Class Diagram
Recoverable Storable Facility
157/30/02 dbh0201
Limitations of Implementation
Available only on ISE Eiffel Dependent upon implementation of STRING and ARRAY not
changing (STRING actually changed once, requiring mitigation) Cannot detect the change of an attribute type when one reference
type is changed to another Cannot restore changes to attributes of type INTEGER_8,
INTEGER_16, INTEGER_64, WIDE_CHARACTER, or BIT Enhancements to INTERNAL in EiffelStudio 5.2 will allow for
support of the new integer types. Lack of capability of INTERNAL to store an attribute of expanded
type requires use of an external call to a low-level run-time routine, thus preventing a pure Eiffel solution.
Recoverable Storable Facility
167/30/02 dbh0201
Potential Improvements
Use XML to store meta-representation instead of using STORABLE. Removes dependency upon an unchanging
implementation of STRING and ARRAY types. If the necessary features are added to INTERNAL, the
remaining implementation limitations will be removed.
Recoverable Storable Facility
177/30/02 dbh0201
Getting Recoverable Storable
The latest version of the Recoverable Storable Facility can be found at:
http://DarrenHiebert.com