Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1997-11-06
2003-12-23
Channavajjala, Srirama (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06668257
ABSTRACT:
BACKGROUND INFORMATION
1. Field of Invention
This invention represents a system for migrating persistent objects when their class declarations are modified.
2. Background Art
The literature defines an “object-oriented” program as one that (1) uses objects, not algorithms as its functional building blocks, (2) has each object being an instance of some class, and (3) has classes related to each other via inheritance relationships. An “object” comprises a data structure and a set of operations or set of methods, that can access and manipulate data. A “Class” is an abstract representation of an object and can be seen as a template for an object. An executing software program creates instances of these Classes called objects. Classes can be interrelated via an inheritance relationship to facilitate class data and operation reuse.
For example, we can create an abstract class termed “employee” that comprises the data and operations common to all employees. We can then create more specific employee classes called “Full-Time” and “Part-Time” to represent two specific employees. The “Full-Time” and “Part-Time” classes which have inheritance relationships with the Employee Class, will inherit the common data and operations from the abstract Employee Class. Interrelated classes form a class hierarchy whose topmost class is termed the “Root”. Abstract classes are super-classes of more specific derived classes. Derived classes are subclasses of more abstract classes. A single inheritance class hierarchy is a hierarchy in which each class in the hierarchy can have no more than one parent. Whereas a multiple inheritance hierarchy is a hierarchy in which each class in the hierarchy can have more than one parent.
Regarding the term “persistence”, it can be defined as follows. In “Object-Oriented-Programming, the permanence of an object, particularly relevant in the context of object-oriented databases, which maintains a distinction between objects created only for the duration of execution and those intended for permanent storage.
When an object-oriented program executes, it creates objects as specified by a program. These objects are created in temporary memory. The memory is termed temporary as the contents of this memory are lost whenever the program terminates. If a program needs to have objects persist even when the computer program terminates, then the program needs to store the created objects out to permanent storage, typically in hard drive. This is usually performed by creating a persistence class that declares the data and operations necessary for writing and reading (their data members) to and from permanent memory. All objects that need to be stored persistently must be instances of a class that has either a direct or transitive inheritance relationship with this persistence class.
The persistence class usually has at least two virtual operations declared that are implemented by all derived classes. One operation writes each of the object's class data members out to a buffer and the other operation reads data from a buffer and initializes an object's class data members. The write operation usually begins at the top of the object's class hierarchy, writes out the class identifier (usually some number) and then writes out the data members to a buffer. When this is done, control is passed to a subclass in the class hierarchy and the same write operation is performed for that class. This is continued until there are no more subclasses in the class hierarchy. The buffer is then written to permanent storage.
This process is reversed when recreating, the object from permanent storage. A buffer is filled with data, the first field of which is a class identifier. This is used to create an object of the specified class. Control is then passed to the virtual read operation of the topmost class in the class hierarchy. This operation reads data from the buffer and initializes the data members. Control is then passed to the subclass and the process is repeated all the way down the class hierarchy.
The problem with saving and retrieving objects from permanent storage arises when an object's class hierarchy is modified. If a new class hierarchy relationship is added or removed from any class declarations that form part of a persistent object's declaration, that object will not be able to be recreated in temporary memory. This is because the content of the data buffer and the control passing between classes and their subclasses will be out of sync. If a class is inserted or appended to a persistent object's class hierarchy, then the contents of the buffer read operation will not match the member data of the appended or inserted class, The program will thus terminate with an error.
A typical solution to this problem is to create a text representation of the persistent objects. When the class hierarchy is modified, the text form representation is read into a parser, tokenized into atomic elements and then used to recreate all the objects, often in temporary memory. These objects are then stored persistently and the problem is alleviated.
SUMMARY OF INVENTION
This invention takes a more automated approach to the problem of migrating persistent objects when their class declarations are modified. It does so in a manner that relieves the user from having to migrate their persistent objects whenever there is a program modification. Objects are automatically migrated to new class hierarchy declarations and stored in permanent memory. First, both the objects and their class descriptions are persistently stored and the persistent version of an object's class description is compared against a later version of an object's class description. The system then migrates objects from their previous version to the later version based on the differences between the two class descriptions. Finally, the system persistently stores the migrated object with its new class description.
REFERENCES:
patent: 5295256 (1994-03-01), Bapat
patent: 5499365 (1996-03-01), Anderson et al.
patent: 5535389 (1996-07-01), Elder et al.
patent: 5664182 (1997-09-01), Nierenberg et al.
patent: 5797007 (1998-08-01), Erickson et al.
patent: 5809507 (1998-09-01), Cavanaugh, III
patent: 5848419 (1998-12-01), Hapner et al.
Castellucci Frank
Greef Arthur Reginald
Maguire Thomas Robert
Channavajjala Srirama
Meyers Steven J.
LandOfFree
Migrating non-persistent objects when one or more of the... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Migrating non-persistent objects when one or more of the..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Migrating non-persistent objects when one or more of the... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3181188