Persistent Object, Persistence Model and Persistent Programming Language

In traditionally programming environments, data is classed as short-term data and long-term data. Short-term data refers to data that is unavailable after the program ends. Long-term data refers to data that survives after the program ends. Traditional programming languages, such as Pascal, C, C++, and so on, manipulate data in a form of variables or objects. However, variables or objects are short-term data, which will disappear after the program ends. In this sense, traditional programming languages are only suited for manipulating short-term data. As for manipulating long-term data, it is the job of the file system or the database management system (DBMS). The file system and DBMS manipulate long-term data in a form of files, tables, records or fields. As a result, the different views of data bring programmers a lot of coding work on the translation between short-term data and long-term data, if the application need manipulate long-term data.

Given an application need keep a tree long-lived, programmers have to write a lot of code on traveling the tree and saving all the nodes into a file - translate short-term data into long-term data. For fetching the tree, programmers are required to write many other source lines reading all the nodes from the file and reconstructing the tree in memory - translate long-term data into short-term data. This translation, sometimes called impedance mismatch, has been estimated to be at least 30% of the total code for a typical database application []. More complex the long-term data is, more code the translation requires. Given that we are modeling a Boeing 747 with traditional programming environments, such a translation will become a tremendous work [].

Besides database applications, general-purpose applications require manipulating long-term data also. With the advance of multimedia technologies, applications are required to support more interactions and user-customization. For example, an interactive application may be required to support a customizable menu/toolbar. For saving the items of the menu/toolbar, programmers usually have to write a routine iterating all items and saving them into a file or the registry. For fetching the menu/toolbar, another routine is required to read all items and reconstruct the menu/toolbar in memory. If the items have complicated properties, such as some graphic or multimedia data, the coding work will become trivial and unpleasant.

The example above shows that the traditional model of manipulating long-term data cannot satisfy the new requirements. A new model is required to manipulate long-term data and short-term data in a single, unified view. This unified view is required to offer a kind of lifetime transparency so that programmers can create, destroy, and access long-term data and short-term data in the same way. This model is known as a persistence model [], which is capable of offering the lifetime transparency, termed persistence transparency []. To offer persistence transparency, all persistence models support long-term objects, known as persistent objects. To access persistent objects, programmers can use a programming language that supports persistent objects. Such a programming language is known as a persistent programming language.

Using a persistent programming language, programmers can easily implement the customizable menu/toolbar mentioned before: programmers merely mark the menu/toolbar object and all item objects as persistent. Then, the programming language will perform the translation automatically, which is transparent for programmers. Given that we use a persistent programming language to model a Boeing 747, we can improve productivity dramatically [].