next up previous contents index
Next: Functions without Command Up: Representation & Implementation Previous: Updating the Session

Linking

We use backward links to link command object together which are stored as proper links in the object versions attached to their root ends. For the backward linking, the update of the command history is done according to:

  1. For each command (workspace and database): add a new version to the session history object and fill in the appropriate values.

  2. If it is a workspace command, then store the command node in the database and end the update.

  3. Otherwise add a new link group CH:Prev_command command to the command node. In this link group we store links to the previous database commands, i.e. the ones that were front commands when we started to update the command history. These are found by traversing the latest of the ch object and retrieving the `Front' link in each of the latest versions.   

  4. Next we create a new version of the ch object and store a link `Front' that points to the new command node. The latest version of ch object is set to be this new ch object version.

  5. Finally, store the new ch object version.

It is however important to note that the succession relation is indirectly available in the temporal development of the ch object. We illustrate this in figure 15, which corresponds to the following chain of events.

At first, there are no commands in the command history. This is represented as a special null-command node (the null-command node is used because we want to have exactly one start node in the command history, it also simplifies the update, since the initial case is included in the normal update case). Then one user executes a database command (e.g. a login). To update the command history, he retrieves the then current ch object (figure 15 (a)). Before he stores the updated ch object another user executes a database command and therefore retrieves the same (still current) version of the ch object. After this, the first user stores his new ch object and the second user finish his updating and stores his new ch object in the database. We have then the situation showed in figure 15 (b), where the ch object has parallel versions. The parallel versions of the ch object corresponds directly to the parallel occurrence of database commands. Continuing the example, the first user executes a sequence of workspace commands, and then another database command, which results in a command history as in figure 15 (c).

 


:  An example of how the command history evolves.

As we see in figure 15, the temporal history of the ch object (available in the VSNET group of the history structure node for the ch object) always reflects the history of database commands. To be able to use it for traversing the command history in succession order, we add a back link for each Front link, as illustrated in figure 16.    

The back link has not been implemented, since the management of the temporal history is currently being changed. When the back link is added it might be called `CH:succ command' to reflect that it contains (indirectly) links to succeeding database commands.

 


:  Connections command history - ch object



next up previous contents index
Next: Functions without Command Up: Representation & Implementation Previous: Updating the Session



Martin Sjolin
Thu Jun 15 20:41:59 MET DST 1995