This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: 31 Object persistence and databases E xecuting an object-oriented application means creating and manipulating a certain number of objects. What happens to these objects when the current execution terminates? Transient objects will disappear with the current session; but many applications also need persistent objects, which will stay around from session to session. Persistent objects may need to be shared by several applications, raising the need for databases . In this overview of persistence issues and solutions we will examine the three approaches that O-O developers have at their disposal for manipulating persistent objects. They can rely on persistence mechanisms from the programming language and development environment to get object structures to and from permanent storage. They can combine object technology with databases of the most commonly available kind (not O-O): relational databases . Or they can use one of the newer object-oriented database systems , which undertake to transpose to databases the basic ideas of object technology. This chapter describes these techniques in turn, providing an overview of the technology of O-O databases with emphasis on two of the best-known products. It ends with a more futuristic discussion of the fate of database ideas in an O-O context. 31.1 PERSISTENCE FROM THE LANGUAGE For many persistence needs it suffices to have, associated with the development environment, a set of mechanisms for storing objects in files and retrieving them from files. For simple objects such as integers and characters, we can use input-output facilities similar to those of traditional programming. Storing and retrieving object structures As soon as composite objects enter the picture, it is not sufficient to store and retrieve individual objects since they may contain references to other objects, and an object deprived of its dependents would be inconsistent. This observation led us in an earlier chapter to the Persistence Closure principle, stating that any storage and retrieval mechanism must handle, together with an object, all its direct and indirect dependents. The following figure served to illustrate the issue: See Deep storage: a first view of persis- tence, page 250 . OBJECT PERSISTENCE AND DATABASES 31.1 1038 The Persistence Closure principle stated that any mechanism that stores O1 must also store all the objects to which it refers, directly or indirectly; otherwise when you retrieve the structure you would get a meaningless value ( dangling reference ) in the loved_one field for O1. We saw the mechanisms of class STORABLE which provide the corresponding facilities: store to store an object structure and retrieved to access it back. This is a precious mechanism, whose presence in an O-O environment is by itself a major advantage over traditional environments. The earlier discussion gave a typical example of use: implementing the SAVE facility of an editor. Here is another, from ISEs own practice. Our compiler performs several passes on representations of the software text.practice....
View Full Document