Presentation on theme: "7/30/02 dbh0201 Recoverable Storable Facility 1 The Recoverable Storable Facility A Mismatch Correction Mechanism for Handling Schema Evolution in an Eiffel."— Presentation transcript:
7/30/02 dbh0201 Recoverable Storable Facility 1 The Recoverable Storable Facility A Mismatch Correction Mechanism for Handling Schema Evolution in an Eiffel System by Darren B. Hiebert
7/30/02 dbh0201 Recoverable Storable Facility 2 References nSection 31.3 of Object-Oriented Software Construction, 2 nd 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.
7/30/02 dbh0201 Recoverable Storable Facility 3 Problem nHow 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)? nIf the object was stored using the facilities of the ISE (now Eiffel Software) class STORABLE, the system will exit with a retrieval exception. uThis discourages its use in any application where preservation of data is important. nRecoverable Storable is an implementation of the solution proposed in OOSC, with minor variations.
7/30/02 dbh0201 Recoverable Storable Facility 4 Definitions n“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] n“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]
7/30/02 dbh0201 Recoverable Storable Facility 5 Solutions nThrow away pre-existing stored objects uSimplest approach uUpsets users nOne-time, en-masse, conversion of stored objects (i.e. “database conversion”) uRequires down-time of application uMultiple conversions require careful sequencing nOn-the-fly object conversion uA more general solution than en-masse conversion, allowing it to be used to implement en-masse conversion uRequires no down-time of application
7/30/02 dbh0201 Recoverable Storable Facility 6 On-the-fly Object Conversion Consists of three phases: nDetection uRetrieval subsystem detects object mismatches. nNotification uRetrieval subsystem notifies retrieving system of object mismatch (appropriate correction is application- dependent). nCorrection uRetrieving system corrects object mismatch using domain-specific knowledge.
7/30/02 dbh0201 Recoverable Storable Facility 7 Detection of Object Mismatch Two Approaches: nNominal uReads version number of generating class recorded in object. uRequires low-level run-time support. nStructural uDetected by recording, for each object, “a class descriptor deduced from the actual structure of a class.” [OOSC p. 1043] uThe 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]
7/30/02 dbh0201 Recoverable Storable Facility 8 Notification of the Retrieving System nProposed solution from OOSC: uClass 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. uClass ANY also contains a “once” function, mismatch_information, of type ANY to provide correct_mismatch with more information.
7/30/02 dbh0201 Recoverable Storable Facility 9 Correction of Object Mismatch nProposed solution from OOSC: uThe procedure correct_mismatch from ANY has a default implementation of raising an exception. uA class which can undertake object mismatch correction redefines correct_mismatch. nTwo mismatch scenarios must be considered: uRemoval of attribute No action required, since attribute is no longer referenced uAddition of new attribute Requires initialization of some kind uOther problems (e.g. change of attribute name or type) are reducible to a combination of the above two problems.
7/30/02 dbh0201 Recoverable Storable Facility 10 Addition of Attribute nThe retrieval subsystem initializes new attributes to default values (as in object creation). nThe 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. uThe purpose of a creation routine is to establish the class invariant of the newly created object. uLikewise, the purpose of correct_mismatch is to re- establish the class invariant of the retrieved object. uThe correct_mismatch procedure may also require access to removed or original attributes in order to do its job.
7/30/02 dbh0201 Recoverable Storable Facility 11 Recoverable Storable nDecomposes objects in the supplied object tree into a meta-representation nConstructs a class descriptor by using the reflection facilities available in ISE Eiffel through its INTERNAL class nUses STORABLE to store the meta-representation of the object tree nProvides capability to rename a class uHandles the case where the name of the generating class of a retrieved object has changed uNew extension to basic solution proposed in OOSC uName translation can be controlled programmatically or via a text file referenced by an environment variable
7/30/02 dbh0201 Recoverable Storable Facility 12 Recoverable Storable (continued) nSince correct_mismatch is not included in the delivered ANY class, the proposed solution from OOSC would require a modification to ANY. uTo avoid modification of the delivered ANY class, Recoverable Storable introduces, instead, the class CORRECTABLE, containing correct_mismatch and mismatch_information. uIf an object mismatch is detected and its generating class in the retrieving system is a descendent of CORRECTABLE, then correct_mismatch is called. nCORRECTABLE and correct_mismatch are deferred, since a default implementation is unnecessary.
7/30/02 dbh0201 Recoverable Storable Facility 13 Recoverable Storable (continued) nThe 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. uAll of the original attributes of the retrieved object are available to correct_mismatch.
7/30/02 dbh0201 Recoverable Storable Facility 14 Class Diagram
7/30/02 dbh0201 Recoverable Storable Facility 15 Limitations of Implementation nAvailable only on ISE Eiffel nDependent upon implementation of STRING and ARRAY not changing (STRING actually changed once, requiring mitigation) nCannot detect the change of an attribute type when one reference type is changed to another nCannot restore changes to attributes of type INTEGER_8, INTEGER_16, INTEGER_64, WIDE_CHARACTER, or BIT uEnhancements to INTERNAL in EiffelStudio 5.2 will allow for support of the new integer types. nLack 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.
7/30/02 dbh0201 Recoverable Storable Facility 16 Potential Improvements nUse XML to store meta-representation instead of using STORABLE. uRemoves dependency upon an unchanging implementation of STRING and ARRAY types. nIf the necessary features are added to INTERNAL, the remaining implementation limitations will be removed.
7/30/02 dbh0201 Recoverable Storable Facility 17 Getting Recoverable Storable nThe latest version of the Recoverable Storable Facility can be found at: http://DarrenHiebert.com